Re: [BEHAVE] [NAT64] Hairpinning loop

["Dan Wing" <dwing at cisco.com>]

> -----Original Message-----
> From: behave-bounces at ietf.org 
> [mailto:behave-bounces at ietf.org] On Behalf Of Simon Perreault
> Sent: Saturday, November 07, 2009 9:56 PM
> To: Brian E Carpenter
> Cc: draft-ietf-behave-address-format at tools.ietf.org; 'Behave 
> WG'; Dan Wing
> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> 
> Brian E Carpenter wrote:
> > On reading section 6 a few times, I couldn't figure out a case where
> > sending a hairpin packet would actually have any value to a user.
> > There will always be another way of reaching the intended 
> destination
> > with a native IPv6 address.
> 
> RFC 4787 section 6, RFC 5382 section 7.2, and RFC 5508 
> section 5 address
> this for the IPv4-IPv4 case.
> 
> Does this still apply for IPv6-IPv4?

Yeah, I might only know my peer's IPv4 address, because my application
only refers IPv4 addresses.  An application might do that to maintain
compatibility with IPv4-only hosts (which can only understand IPv4
addresses).  I discuss this situation in
draft-wing-behave-nat64-referrals-01.txt
for a couple of protocols.

We might imagine that applications would refer IPv6 (when available)
and also IPv4.  That works, but it's possible to get referred through
an IPv4-only node, which would remove the IPv6 address (a case where
referring from A to B to C, where "B" is IPv4-only and the others
are trying to do the right thing and refer both IPv6 and IPv4.

-d


> 
> Simon
> -- 
> DNS64 open-source   --> http://ecdysis.viagenie.ca
> STUN/TURN server    --> http://numb.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave