Subject: [Ietf-behave] IP options and NATs

From: "Dan Wing" <[email-masked]>
Date: Wed, 2 Aug 2006 09:19:44 -0700 (PDT)

While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, I noticed:

    >     The discussion in this document is based on the
    >     following assumptions.  
    >     ...
    >     6.  The legacy NAT does not drop IP packets with a
    >         Router Alert Option (RAO) or an IPv6 extensions
    >         header.  Furthermore, the RAO or extension header
    >         is also present in the forwarded packet.  If the
    >         NAT does not do this, then there is no way for a
    >         GIST QUERY to traverse the NAT, which is a
    >         prerequisite for the mechanisms described in this
    >         document.

I am wondering how today's NATs handle IP options.  I asked our engineering
teams and found that Cisco's IOS NAT preserves IP options across the NAT,
but our PIX and our ASA drop all IP options.  Testing will be necessary to
determine how various residential style NATs (Linksys, etc.) handle IP
options such as RAO.

Does anyone know what other NATs do with RAO?

-d

---

From: "Dave Hudson" <[email-masked]>
Date: Wed, 2 Aug 2006 09:27:23 -0700 (PDT)

I certainly know of quite a number of residential NATs that discard IP
options.

On the slightly related subject of things being discarded I also know of
several that discard DSCP information too.

Regards,
Dave

* -----Original Message-----
* From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
* [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dan Wing
* Sent: 02 August 2006 17:20
* To: ietf-behave@xxxxxxxxxxxxxxxxxxx
* Cc: 'Pashalidis, Andreas'
* Subject: [Ietf-behave] IP options and NATs
* 
* While reviewing draft-pashalidis-nsis-gist-legacynats-00.txt, 
* I noticed:
* 
*     >     The discussion in this document is based on the
*     >     following assumptions.  
*     >     ...
*     >     6.  The legacy NAT does not drop IP packets with a
*     >         Router Alert Option (RAO) or an IPv6 extensions
*     >         header.  Furthermore, the RAO or extension header
*     >         is also present in the forwarded packet.  If the
*     >         NAT does not do this, then there is no way for a
*     >         GIST QUERY to traverse the NAT, which is a
*     >         prerequisite for the mechanisms described in this
*     >         document.
* 
* I am wondering how today's NATs handle IP options.  I asked 
* our engineering teams and found that Cisco's IOS NAT 
* preserves IP options across the NAT, but our PIX and our ASA 
* drop all IP options.  Testing will be necessary to determine 
* how various residential style NATs (Linksys, etc.) handle IP 
* options such as RAO.
* 
* Does anyone know what other NATs do with RAO?
* 
* -d
* _______________________________________________
* Ietf-behave mailing list
* Ietf-behave@xxxxxxxxxxxxxxxxxxx
* https://list.sipfoundry.org/mailman/listinfo/ietf-behave
* 
*

---

From: Lars Eggert <[email-masked]>
Date: Wed, 2 Aug 2006 11:23:54 -0700 (PDT)

On Aug 2, 2006, at 18:19, Dan Wing wrote:
I am wondering how today's NATs handle IP options.
Alberto Medina, Mark Allman, Sally Floyd. Measuring the Evolution of  
Transport Protocols in the Internet. ACM Computer Communication  
Review, 35(2), April 2005. http://www.icir.org/mallman/papers/tcp-evo- 
ccr05.ps

It's not about NATs in particular, but just probes a large number of  
Internet paths, and sure enough, *something* out there drops IP options.

Lars
--
Lars Eggert                                     NEC Network Laboratories

Attachment:
smime.p7s