Re: ND-proxy applicability in Unmanaged [Re: WG Last Call: draft-ietf-v6ops-unmaneval-01.txt]

["Mohan Parthasarathy" <mohanp@sbcglobal.net>]

> > Luckily enough ND-proxy is not going to be IETF standard, but
> > Informational :).  Nobody has bothered to document (different
flavors
> > of) proxy-ARP, but that's there in the similar way as well --
without
> > spanning tree, and seems to be working whereever it's used.
>> 
>> Sorry, I missed the last sentence.
>> 
>> The proxy arp implementations I know of decrement ttl.
>> Are there proxy arp implementations that do not decrement ttl?
>> 
>> Can't compare that with ndproxy which doesn't decrement the hop count.

>Actually, I know of quite a few NAT boxes that do not decrement the TTL.

Any reason why these boxes don't do it ? I thought that one of the original versions
of the ND proxy draft specified that hop limit would be decremented. Was it removed
later ? What is the reason for not needing hop count decrementing in ND-proxy ?

thanks
mohan

>I see "ndproxy" in much the same light as I see NAT: a cheap hack that
>allows multiple hosts to connect to a single attachment without
>explicitly requiring individual addresses or an explicit prefix. In the
>same application domain, I would rather see vendors shipping an IPv6
>ndproxy than an IPv6 NAT. 

>Basic NDproxy only works with limited topologies. However, it does work
>well with the simple "single subnet in the home" topology. In that
>topology, even SEND makes sense -- at least between machines on the home
>network. The combination of "works well in many cases" and "can be
>deployed autonomously" is known to guarantee some deployment -- much
>like the same properties allowed the deployment of NAT, even as NAT were
>not described in any IETF standard. 
>
>I agree that IETF standardization should focus on multi-link subnets,
>which solves the very nasty "cascade of NAT" problems. However, there is
>a lot of value in a document that says "if you were thinking of
>developing an IPv6 NAT, please do NDproxy instead". The proper procedure
>may in fact be a publication as proposed standard, that could then be
>made obsolete by the proposed standard for multi-link subnets.

-- Christian Huitema