Re: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

["George, Wes E IV [NTK]" <[e-mail]>]

Of course immediately after I send this, I find some language that might work:

http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-01

Perhaps these drafts should be integrated or at least reference one another since there is good info in both and some overlapping details between shared addressing and true 1918 private addressing?

Thanks
Wes George



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of George, Wes E IV [NTK]
Sent: Monday, October 04, 2010 2:16 PM
To: Laganier, Julien; [e-mail]
Cc: [e-mail]; Christian Vogt
Subject: Re: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

I have a few comments on section 9 - you make reference to ICMP in the context of MTU only as it relates to an attack vector. In reality, there are more potential issues surrounding MTU that could be discussed in more detail in this document.

The issue of how to make PMTUd work is implicitly covered from the perspective of special handling of ICMP that would be required to forward ICMP (including packet too big) messages to the end hosts, but you would do well to draw a clearer linkage between ICMP forwarding and MTU discovery. Perhaps a reference to existing standards about which ICMP messages are critical and should not be blocked would be of value here, to give potential implementers an informative reference when it comes to special handling of ICMP.

Regarding caching a small MTU value on the remote end and it affecting multiple hosts behind the shared address, that is also an issue if the MTU behind the shared address infrastructure is not uniform. What if it caches a value that is too high or too low due to a previous ICMP packet too big message, but instead of it being 68, it's still a legitimate value? (1400 instead of 1500, or 1800 instead of 1300, for example) The concerns about increased load are still valid, and this is a much more likely scenario.

There's also the question of whether the address-sharing infrastructure caches MTU info in the other direction (from destinations its hosts have sessions with) and tries to do its own PMTUd that it then can respond directly to the host with the appropriate ICMP message vs relying on the end host to manage that via forwarded ICMP messages. I'd say that most likely this represents an unacceptable level of state to maintain, but maybe it's worth explicitly covering it.

Thanks
Wes George


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Laganier, Julien
Sent: Thursday, September 30, 2010 3:24 PM
To: [e-mail]
Cc: [e-mail]; Christian Vogt
Subject: [Int-area] WGLC for draft-ietf-intarea-shared-addressing-issues-01

Folks,

This note initiates a two weeks WG Last Call for http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues-01

Please review the draft and send your comments to the mailing list before 2010-10-14 COB PST. Please also state whether or not you think the draft is ready to be forwarded to IESG for publication as an Informational RFC.

Thank you for your support.

--julien & christian
_______________________________________________
Int-area mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/int-area


This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

_______________________________________________
Int-area mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/int-area


This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.