Subject: [Mip6] Increment/Decrement TTL when traversing NAT (DS-MIPv6)

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 22:59:15 +0200

Should the draft specify that both MN and HA should increment and
decrement TTL of the IPv4 header when de- and en-capsulating in UDP?

RFC 3519 (MIP4 NAT traversal) only talks about decrementing the TTL, not 
incrementing.

Alex

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Apr 2006 23:28:08 +0200

Alexandru Petrescu wrote:
> RFC 3519 (MIP4 NAT traversal) only talks about decrementing the TTL, 
> not incrementing.

Me again, sorry for following up my own question.  Both MN and HA should
only decrement the TTL.  The other end should not increment it back.
Because the whole meaning of TTL is to be decremented when traversing
links, such that PMTU and other protocols can work.

Thus, if the UDP tunnel is actually a link (RFC 3519 says TTL is
decremented) then the HA attached to it, being a router, could send RAs
on it, no?  I mean nobody forbids it to do so, it's even recommended by
some RFC.  Besides, at least one widespread implementation (radvd) can
do it, I've tried.  So again, why not doing it?

More in its favor: setting up a 6to4 on MN behind some gentle NAT (read
one allowing IPv6-in-IPv4,) is a breeze on linux.  Once connected to the
IPv6 with 6to4 one can obviously run standard MIP6.  When connected to
6to4 the MN gets a real IPv6 CoA, so run 3775/6 MIP6.  Don't trust me:
try it.

So, why not having an IPv6 real address over the UDP tunnel too?

Alex