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
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, Steven M. Bellovin
Only the end-to-end principle...
Perhaps not relevant, but between any two consenting nodes, there can be severe mangling of headers as long as what comes out the other side looks pretty much the same as what went in. CSLIP is an example of this.
Regards,
-drc
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