Fwd: I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error Messages

[Rémi Després <remi.despres@free.fr>]

Retransmission to the list (omitted by mistake).

Début du message réexpédié :

> De : Rémi Després <remi.despres@free.fr>
> Date : 8 mars 2010 09:22:38 HNEC
> À : james woodyatt <jhw@apple.com>
> Cc : Brian E Carpenter <brian.e.carpenter@gmail.com>
> Objet : Rép : I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error Messages
> 
> James,
> 
> Sorry to come so late on this tread.
> But the point below is IMHO important.
> 
> In the draft, the only REC-n concerning ICMP is so far:
> "REC-16: If a gateway forwards a UDP exchange, it MUST also forward ICMP Destination Unreachable messages containing UDP headers that match the exchange state record."
> 
> In my understanding, what is needed is, for each of the transport protocols:
> "REC-n: If a gateway forwards a NNN exchange, it MUST also forward, in both directions, ICMP Error messages containing UDP headers that match the exchange state record."
> 
> - Forwarded error messages must be also for TCP, DCCP, etc., and must be more general than just Destination Unreachable: they must include in particular Packet Too Big notifications which are essential for IPv6 path-MTU discovery.
> - Reliable PMTUD is much more important in IPv6 than in IPv4.
> While IPv4 packets can be fragmented within the network where they are too long for the local MTU, IPv6 fragmentation is only end to end. 
> Thus, as long as PMTUD cannot be considered reliable, all IPv6 MTUs must remain clamped to 1280 octets. 
> This is not really dramatic, but is significantly less than optimum in many environments. Furthermore, in dual-stack hosts that apply the same MTU to IPv4 and IPv6, and also to on-link and off-link packets, this limitation spreads out to on-link IPv4 packets, which is also less dramatic than losing connectivity, but is unfortunate.
> 
> I have added Brian as destination because of the point he made, in Softwire, that in IPv6-PMTUD was unreliable.
> 
> Regards,
> 
> RD
> 
> 
> 
>> everyone--
>> 
>> Once again, I'd like to ask for some discussion and feedback on this draft.  Is there any reason this revision of the draft should not proceed to Working Group Last Call at this time?
>> 
>> 
>> --
>> james woodyatt <jhw@apple.com>
>> member of technical staff, communications engineering
>> 
>> 
>> 
>