Types of packet modifications allowed for networks
I would like any pointers to good documents that outline what sort of packet modifications are allowed (in terms of Internet culture/policies) by networks. Notably: For a transit network (neither sending or destination IPs belong to the network) For the sending network (originating IP belongs to that network) For the destination network (destination IP belongs to that network). Obviously, every router will change/decrement the TTL (and recalculate the header checksum) in the IP header. Are there other fields that are routinely changed at every hop ? Would it also be correct to state that any network along the way would have the right to fragment a packet in two or more pieces ? Or would that only be the destination network needing to fragment a packet to fit the last mile (PPP dialup or PPPoE ) in cases where MTU negotiations failed ? Are there sacred rules documented anywhere about not modifying anything else in the packets during transit ? Or has there never been any formal documentation on this because it was so obvious nobody was allowed to modify packets in transit ? (I an in Canada and currently participating in CRTC proceedings about the Bell throttling issue, and would like to consider the angle where the CRTC might decides Bell has the right to manage PPPoE packets as if they were TCPIP packets (by looking inside). Thanks in advance for any hints/pointers on this issue.
I'm not aware of any hard rules regarding this. I'll include yours below: --packet fragmentation due to inconsistent MTUs and/or bandwidth (e.g. moving from ATM at 150Mbps to a fractional DS3 at 3.088Mbps) --ttl changes from hop to hop --dest ip changes from hop to hop --PAT/NAT changes in last network borders (e.g. routing traffic to appropriate endpoints (servers) or starting points (workstations)) --PAT/NAT changes in "last" host (e.g. it hits ext ip port 4443, gets changed to newip:443 and forwarded on) --firewall changes in buffer/mother network (e.g. protective network or DMZ)--these could be almost anything, most frequent would be morons who completely block ICMP--you should probably count anti-spam and anti-virus (layer 4 but affects layer 3 dramatically) but these are usually advertised features subscribed to by the customers (as opposed to secret "features" that only come out due to customer outrage) --header checksum changes after contents changes (e.g. dip at a router) Meh, not sure I was helpful. --p
Darden, Patrick S. wrote:
--packet fragmentation due to inconsistent MTUs and/or bandwidth (e.g. moving from ATM at 150Mbps to a fractional DS3 at 3.088Mbps)
MTUs yes, bandwidth no. Bandwidth congestion at the boundary to a slower network will cause buffering and dropped packets, not a fragment. Trying to fit a jumbo frame packet into a standard MTU network _will_ (if the DF bit is not set).
--ttl changes from hop to hop
Decrements, yes.
--dest ip changes from hop to hop
Say what? The L2 address might change at each hop (eg, MAC address of the next gateway in ethernet type networks) but the L3 destination address, which is the "destination IP", certainly doesn't. If it did how would the packet ever get to where it was sent?
--PAT/NAT changes in last network borders (e.g. routing traffic to appropriate endpoints (servers) or starting points (workstations))
NAT/PAT can occur at any point in the network, but is most common at the edges.
--PAT/NAT changes in "last" host (e.g. it hits ext ip port 4443, gets changed to newip:443 and forwarded on)
Same.
--firewall changes in buffer/mother network (e.g. protective network or DMZ)--these could be almost anything, most frequent would be morons who completely block ICMP--you should probably count anti-spam and anti-virus (layer 4 but affects layer 3 dramatically) but these are usually advertised features subscribed to by the customers (as opposed to secret "features" that only come out due to customer outrage)
This is rather common, especially things like resetting the QOS bits, clearing the DF flag, etc.
--header checksum changes after contents changes (e.g. dip at a router)
TTL being decremented is enough. Cheers Darryl -- Darryl Ross, VK5FUNE Director, AFOYI, "Information Technology Solutions" p +61 8 7127 1831 f +61 8 8425 9607 e darryl@afoyi.com
I was reminded by the "packet modifications" thread that it seems that dropping (rather than fragmenting) large UDP packets has become quite the norm, which is unfortunate. We're working on a (popular software) product that sends UDP datagrams (with DF cleared), and it is amazing how small they have to be to get through. Between the Cisco VPN software and the high-end NAT boxes that have broken hairpin behavior and broken consumer "routers", we're finding that whereas sizes in the mid 1400-byte range used to be safe, going much over 1200 bytes is now routinely a problem. Path MTU discovery (PLPMTUD) shouldn't need to be looking for and finding black holes when the DF flag is cleared, but that's what we're having to implement to work on today's Internet. Operational relevance: 1) This software will be running on your networks, and your customers will be happier if you don't drop UDP datagrams that are of reasonable size, 2) Knowing that this is going on might help you debug problems customers are having with other applications if you didn't know already how bad it has gotten. Matthew Kaufman matthew@eeph.com http://www.matthew.at
On Sat, 31 May 2008 17:59:40 -0400 Jean-François Mezei <jfmezei@vaxination.ca> wrote:
I would like any pointers to good documents that outline what sort of packet modifications are allowed (in terms of Internet culture/policies) by networks.
Notably:
For a transit network (neither sending or destination IPs belong to the network)
For the sending network (originating IP belongs to that network)
For the destination network (destination IP belongs to that network).
Obviously, every router will change/decrement the TTL (and recalculate the header checksum) in the IP header. Are there other fields that are routinely changed at every hop ?
Assorted IP options carry network state: Record Route, Loose and Strict Source Route, Timestamp -- see RFC 791. I wouldn't say "routinely", but it is in the spec. I forget the status of the flow label for IPv6.
Would it also be correct to state that any network along the way would have the right to fragment a packet in two or more pieces ? Or would that only be the destination network needing to fragment a packet to fit the last mile (PPP dialup or PPPoE ) in cases where MTU negotiations failed ?
Note that in-flight fragmentation is only permitted for certain packets: one without DF set for IPv4; ones with a fragmentation header for IPv6.
Are there sacred rules documented anywhere about not modifying anything else in the packets during transit ? Or has there never been any formal documentation on this because it was so obvious nobody was allowed to modify packets in transit ?
Only the end-to-end principle... I sometimes see suggestions that routers should be able to add IP options or v6 extension headers. These are known as bad ideas. --Steve Bellovin, http://www.cs.columbia.edu/~smb
participants (6)
-
Darden, Patrick S. -
Darryl Ross -
David Conrad -
Jean-François Mezei -
Matthew Kaufman -
Steven M. Bellovin