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 marcelo bagnulo braun
> Sent: Sunday, November 22, 2009 12:12 AM
> To: Dan Wing
> Cc: 'Behave WG'; 
> draft-ietf-behave-address-format at tools.ietf.org; 'Xing Li'
> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> 
> Dan Wing escribió:
> >> -----Original Message-----
> >> From: behave-bounces at ietf.org 
> >> [mailto:behave-bounces at ietf.org] On Behalf Of Dan Wing
> >> Sent: Saturday, November 21, 2009 2:49 PM
> >> To: 'Xing Li'
> >> Cc: draft-ietf-behave-address-format at tools.ietf.org; 'Behave WG'
> >> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> >>
> >>
> >>  
> >>
> >>     
> >>> -----Original Message-----
> >>> From: behave-bounces at ietf.org 
> >>> [mailto:behave-bounces at ietf.org] On Behalf Of Xing Li
> >>> Sent: Friday, November 20, 2009 10:45 PM
> >>> To: Dan Wing
> >>> Cc: draft-ietf-behave-address-format at tools.ietf.org; 'Behave WG'
> >>> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> >>>
> >>> Dan Wing 写道:
> >>>       
> >>>>> -----Original Message-----
> >>>>> From: Simon Perreault [mailto:simon.perreault at viagenie.ca] 
> >>>>> Sent: Friday, November 20, 2009 9:06 AM
> >>>>> To: Dan Wing
> >>>>> Cc: 'marcelo bagnulo braun'; 'Brian E Carpenter'; 'Behave 
> >>>>> WG'; draft-ietf-behave-address-format at tools.ietf.org
> >>>>> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> >>>>>
> >>>>> Dan Wing wrote, on 2009-11-20 11:59:
> >>>>>     
> >>>>>           
> >>>>>>> mmm, afaiu, if we filter incoming packet containing 
> >>>>>>>         
> >>>>>>>               
> >>>>> Pref64::/n in the 
> >>>>>     
> >>>>>           
> >>>>>>> source address, then we don't have a loop problem.
> >>>>>>>         
> >>>>>>>               
> >>>>>> I guess you're thinking 'loop problem' is avoidable by dropping
> >>>>>> packets?  My worry is that if we drop packets like 
> >>>>>>             
> >> that, we could
> >>     
> >>>>>> break an application that has no other means to contact 
> >>>>>>             
> >>> its intended
> >>>       
> >>>>>> peer.  For example, an application that only knows one IP 
> >>>>>>       
> >>>>>>             
> >>>>> address for
> >>>>>     
> >>>>>           
> >>>>>> its peer, and that IP address is on the 'far' side of the same
> >>>>>> translator that both of them are using.
> >>>>>>       
> >>>>>>             
> >>>>> I don't understand what you're saying. We drop packets using 
> >>>>> Pref64::/n as source.
> >>>>>     
> >>>>>           
> >>>> For stateful, yes, that makes sense.
> >>>>
> >>>> For stateless, I had understood the prefix of the translator
> >>>> and the prefix of the hosts is the same, per the last sentence I
> >>>> am quoting from
> >>>>
> >>>>         
> >>> http://tools.ietf.org/html/draft-ietf-behave-address-format-01
> >>> #section-3.3
> >>>       
> >>>>    Organizations deploying stateless translation SHOULD 
> >>>>         
> >>> assign a Network
> >>>       
> >>>>    Specific Prefix to their translation service.  Both "IPv4
> >>>>    translatable" and "IPv4 Embedded" MUST be constructed as 
> >>>>         
> >>> specified in
> >>>       
> >>>>    section 2.  "IPv4 translatable" addresses MUST use 
> the selected
> >>>>    Network Specific Prefix.  Both types of addresses SHOULD 
> >>>>         
> >>> use the same
> >>>       
> >>>>    prefix. 
> >>>>
> >>>>   
> >>>>         
> >>> Yes. If both types of addresses (IPv4-translatable and 
> >>> IPv4-converted) 
> >>> use the same prefix, then the hairpin function is NOT required.
> >>>       
> >> I disagree.
> >>
> >> The peer's IPv6 address could have been originally communicated
> >> in SIP, XMPP, or whatever, but could have been discarded by an
> >> IPv4-only SIP proxy, IPv4-only SBC, IPv4-only SIP endpoint, 
> >> IPv4-only XMPP endpoint, or whatever.  And when the IPv6-only
> >> endpoint finally receives the referral, it contains only an
> >> IPv4 address.
> >>
> >> Thus, the IPv6 host will only know its peer's IPv4 address -- 
> >> and does not know its IPv4 address.  Because it doesn't know
> >> of the IPv6 host's address, the packet has to be sent to the
> >> translator, and the translator needs to hairpin the packet.
> >>
> >> If we constrain the problem by declaring something like "IPv4
> >> applications should not be discard IPv6 addresses", then I 
> >> agree we don't need hairpinning in the translator.
> >>     
> >
> > Or is it, maybe, that when the peer's IPv6 prefix and the 
> translator's IPv6
> > prefix are the same, the peer's IPv4 representation is the 
> same as the
> > translator's.  I think that must be the situation.  This 
> should be better
> > described in the address-format document; instead of just a 
> SHOULD, describe
> > that it causes normal IPv6 packet routing to allow two IPv6 hosts to
> > communicate directly without going through the translator, 
> because each IPv6
> > host (behind the translator) are effectively doing the same 
> function as the
> > translator
> 
> but wouldn't this require some mechanism in the IPv6 host to do this?

If using DNS, and having a DNS-based referral, the DNS64 will give 
it such an address -- thus, no change in the application.  

If not using DNS64 (as described in draft-wing-v6ops-v6app-v4server),
the application (or the underlying OS) needs to build its own IPv6
destination address.  For that to work, the application (or the 
underlying OS) needs to know the 6/4 translator's prefix in order
to build its own IPv6 destination address.

-d



> Regards, marcelo
> 
> 
> >  (namely, putting the translator's IPv6 prefix [which is also the
> > IPv4 peer's IPv6 prefix] in front of the IPv4 address [using
> > wing-behave-learn-prefix and a translator-aware 
> application, or using DNS64]).
> >
> > -d
> >
> >
> >   
> >> -d
> >>
> >>
> >>     
> >>> xing
> >>>
> >>>
> >>>       
> >>>> -d
> >>>>
> >>>>   
> >>>>         
> >>>>> The IP address on the far side will be an IPv4 
> >>>>> address, which one can
> >>>>> express using an IPv6 address in Pref64::/n, but that will be 
> >>>>> the destination,
> >>>>> not the source.
> >>>>>
> >>>>> 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
> >>>>
> >>>>
> >>>>   
> >>>>         
> >>> _______________________________________________
> >>> Behave mailing list
> >>> Behave at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/behave
> >>>
> >>>       
> >> _______________________________________________
> >> Behave mailing list
> >> Behave at ietf.org
> >> https://www.ietf.org/mailman/listinfo/behave
> >>     
> >
> > _______________________________________________
> > Behave mailing list
> > Behave at ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >
> >   
> 
> _______________________________________________
> Behave mailing list
> Behave at ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>