PMTUD for IPv4 Multicast - How?

I recently discovered that my routers weren't generating ICMP Type 3 Code 4 (unreachable, DF-bit) messages in response to too-big IPv4 multicast packets with DF=1. At first, I thought this was a bug, but then learned that RFCs 1112, 1122 and 1812 all specify that ICMP unreachables not be sent in

Re: PMTUD for IPv4 Multicast - How?

On Mon, 31 Aug 2015 12:12:16 -0400, Chris Marget said: > At first, I thought this was a bug, but then learned that RFCs 1112, 1122 > and 1812 all specify that ICMP unreachables not be sent in response to > multicast packets. > I'm struggling to grok the rationale behind not sending unreachables

Advance notice - H-root address change on December 1, 2015

This is advance notice that there is a scheduled change to the IP addresses for one of the authorities listed for the DNS root zone and the .ARPA TLD. The change is to H.ROOT-SERVERS.NET, which is administered by the U.S. Army Research Laboratory. The new IPv4 address for this authority is

Re: PMTUD for IPv4 Multicast - How?

On Mon, Aug 31, 2015 at 12:37 PM, wrote: > On Mon, 31 Aug 2015 12:12:16 -0400, Chris Marget said: > > > At first, I thought this was a bug, but then learned that RFCs 1112, 1122 > > and 1812 all specify that ICMP unreachables not be sent in response to > > multicast

Re: PMTUD for IPv4 Multicast - How?

> > > At first, I thought this was a bug, but then learned that RFCs 1112, 1122 > > > and 1812 all specify that ICMP unreachables not be sent in response to > > > multicast packets. > > > > > I'm struggling to grok the rationale behind not sending unreachables in > > > response to multicast

Re: PMTUD for IPv4 Multicast - How?

On Mon, Aug 31, 2015 at 3:49 PM, wrote: > ICMP replies to multicast packets can cause ICMP "implosion". This is > not a new discussion - see for instance > > http://mailman.nanog.org/pipermail/nanog/2012-June/048685.html It's a shame we handle path MTU as a layer 3 problem

Re: PMTUD for IPv4 Multicast - How?

Chris Marget wrote: >> For the exact same reason that replying to an ICMP Echo Request sent to >> your broadcast address is generally considered a Bad Idea. >> >> The obvious solution is "Doctor, it hurts when I do that" "Don't do that >> anymore". And, it implies that some ISPs will filter all

Re: PMTUD for IPv4 Multicast - How?

>> I'll probably come around, but I've not yet concluded that "screw it, >> fragment my traffic, I don't care" is the stance that a conscientious >> application should be taking. > > Don't you care, for routers, generating ICMP PTB is as burdensome > as generating fragments? I don't think so. If

Re: PMTUD for IPv4 Multicast - How?

> > It's not as obvious to me as it is to you. I mean, v6 *requires* exactly > > this behavior, so it can't be all that bad, can it? > > ICMP replies to multicast packets can cause ICMP "implosion". This is > not a new discussion - see for instance > >

Re: PMTUD for IPv4 Multicast - How?

On Mon, Aug 31, 2015 at 5:17 PM, Masataka Ohta wrote: > for routers, generating ICMP PTB is as burdensome > as generating fragments? No, it isn't. When a router fragments a packet, it has to fragment the next and the next and the next. Maybe tens or hundreds of

Re: PMTUD for IPv4 Multicast - How?

William Herrin wrote: > It'd make more sense to truncate the > packet, set a flag, and then let layer 4 at the recipient deal with > negotiating a new size with the sender. For routers, truncating the packet and setting a flag is as burdensome as fragmentation or ICMP generation. Moreover, just

Re: PMTUD for IPv4 Multicast - How?

William Herrin wrote: >> for routers, generating ICMP PTB is as burdensome >> as generating fragments? > > No, it isn't. Yes, it is. Generating an ICMP PTB @aclet　is as burdensome as fragmenting　a packet. > When a router fragments a packet, it has to fragment the next and the > next and the

Zero rating implentation strategies

Last year, one large mobile operator in Canada started to zero-rate its own mobile TV offering. It appears that routers kept counting all the data, but that the company then subtracted usage generated by its video servers to come up with billable Gigabytes for each user. (This was quashed by the

Re: PMTUD for IPv4 Multicast - How?

In message <55e4f62b.6060...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > William Herrin wrote: > > >> for routers, generating ICMP PTB is as burdensome > >> as generating fragments? > > > > No, it isn't. > > Yes, it is. Generating an ICMP PTB is as burdensome as > fragmenting a

Re: PMTUD for IPv4 Multicast - How?

Mark Andrews wrote: >> Yes, it is. Generating an ICMP PTB is as burdensome as >> fragmenting a packet. > > Well it could be done at wire speed. Both of them could be. > There is no theoretical reason > why it has to be more burdensome than forwarding a packet. That's not my point. > The

Re: PMTUD for IPv4 Multicast - How?

On Mon, Aug 31, 2015 at 8:55 PM, Masataka Ohta wrote: > Chris Marget wrote: I'll probably come around, but I've not yet concluded that "screw it, fragment my traffic, I don't care" is the stance that a conscientious application should be taking.