Re: PMTUD and MTU < 1280

[Rémi Després <[e-mail]>]

Le 25 juil. 2011 à 20:50, Dan Wing a écrit :

>> -----Original Message-----
>> From: Rémi Després [mailto:[e-mail]]
>> Sent: Monday, July 25, 2011 1:43 PM
>> To: Dan Wing
>> Cc: 'james woodyatt'; 'RJ Atkinson'; [e-mail]
>> Subject: Re: PMTUD and MTU < 1280
>> 
>> Dan,
>> 
>> 1.
>> The point I wanted to check is just, slightly reformulated):
>> "May a simple IPv6 host have no support of packet-reassembly, and
>> simply accept packets up to 1280 octets."
> 
> The earlier part of this thread was talking about sending; you're
> now bringing up receiving.

Yes.

The point made is about the difference between IPv6-to-IPv4 and IPv6-to-IPv6 PMTU's (an IPv6 PTB with MTU < 1280 remaining excluded, AFAIK, if both source and destination are IPv6.) 

> IMO, if the packet came from IPv4, and that IPv4 network had a small
> MTU (e.g., 576) causing fragmentation, then such an IPv6 receiver
> will be unable to receive the packet.

The point is only about IPv6 to IPv6.

>> In my understanding, the answer should be yes.
>> - This doesn't depend on whether sources know or not whether their
>> destinations are IPv6 or IPv4 only.
>> - If the destination happens to be IPv6, current RFC's don't permit
>> intermediate nodes to refuse 1280 packets as being too big.
>> 
>> 2.
>> How sources can be sure to have e2e transparency in IPv6 is a different
>> question, but IMHO an important one.

>> For instance, if a destination address is obtained from the DNS in a
>> AAAA, with no A for the same URL  and without any well-known prefix
>> indicating that there is an embedded-IPv4-address, I hope the source
>> can be guaranteed that e2e transparency won't be broken?
> 
> I don't think so.  DNS64 comes to mind.

In my understanding, a host that requests both for A's and AAAA's, and receives no A, knows it talks to an IPv6-only host, with or without DNS64.
There may be other ways to know it, e.g. for some IPv6-only sensors talking only with IPv6-capable dedicated servers. 

In any case, I have no problem with leaving this subject, as many others may be found more urgent.

Thanks,
RD


>> I won't have time personally to contribute much on this, but the
>> subject would usefully be clarified, IMHO.
> 
> The RFCs are pretty clear, IMO. Implementers don't want to read

> them all the way.
> 
> -d
> 
> 
>> Regards,
>> RD
>> 
>> 
>> Le 25 juil. 2011 à 15:36, Dan Wing a écrit :
>> 
>>>>>> 
>>>>>> ...
>>>>> 
>>>>> Its behavior violates the last paragraph of Section 5 of RFC2460.
>>>> 
>>>> Violation _only in case_ of "an IPv6 packet that is sent to an IPv4
>>>> destination".
>>> 
>>> But how does one determine an IPv6 packet is, or isn't, going
>>> to an IPv4 destination?  I don't think it's possible to determine
>>> if there is an IPv6/IPv4 translator on the path.
>>> 
>>> -d
>>> 
>>> 
>>>> If the destination is IPv6, a PMTU below 1280 remains therefore a
>>>> network failure.
>>>> This authorizes a simple IPv6 host to refuse packets beyond 1280
>> octets
>>>> and to have no support of packet-reassembly.
>>>> 
>>>> Right?
>>>> 
>>>> Regards,
>>>> RD
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> -d
>>>>> 
>>>>>> 
>>>>>> --
>>>>>> james woodyatt <[e-mail]>
>>>>>> member of technical staff, core os networking
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------
>> --
>>>>>> IETF IPv6 working group mailing list
>>>>>> [e-mail]
>>>>>> Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> ------------------------------------------------------------------
>> --
>>>>> 
>>>>> -------------------------------------------------------------------
>> -
>>>>> IETF IPv6 working group mailing list
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> -------------------------------------------------------------------
>> -
>>> 
> 
>