Re: [BEHAVE] [NAT64] Hairpinning loop

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of marcelo bagnulo braun
> Sent: Sunday, November 22, 2009 2:03 PM
> To: Dan Wing
> Cc: 'Xing Li'; 
> [e-mail]; 'Behave WG'
> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> 
> Dan Wing escribió:
> >  
> >
> >   
> >> -----Original Message-----
> >> From: [e-mail] 
> >> [mailto:[e-mail]] On Behalf Of marcelo bagnulo braun
> >> Sent: Sunday, November 22, 2009 12:12 AM
> >> To: Dan Wing
> >> Cc: 'Behave WG'; 
> >> [e-mail]; 'Xing Li'
> >> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> >>
> >> Dan Wing escribió:
> >>     
> >>>> -----Original Message-----
> >>>> From: [e-mail] 
> >>>> [mailto:[e-mail]] On Behalf Of Dan Wing
> >>>> Sent: Saturday, November 21, 2009 2:49 PM
> >>>> To: 'Xing Li'
> >>>> Cc: [e-mail]; 'Behave WG'
> >>>> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> >>>>
> >>>>
> >>>>  
> >>>>
> >>>>     
> >>>>         
> >>>>> -----Original Message-----
> >>>>> From: [e-mail] 
> >>>>> [mailto:[e-mail]] On Behalf Of Xing Li
> >>>>> Sent: Friday, November 20, 2009 10:45 PM
> >>>>> To: Dan Wing
> >>>>> Cc: [e-mail]; 'Behave WG'
> >>>>> Subject: Re: [BEHAVE] [NAT64] Hairpinning loop
> >>>>>
> >>>>> Dan Wing 写道:
> >>>>>       
> >>>>>           
> >>>>>>> -----Original Message-----
> >>>>>>> From: Simon Perreault [mailto:[e-mail]] 
> >>>>>>> Sent: Friday, November 20, 2009 9:06 AM
> >>>>>>> To: Dan Wing
> >>>>>>> Cc: 'marcelo bagnulo braun'; 'Brian E Carpenter'; 'Behave 
> >>>>>>> WG'; [e-mail]
> >>>>>>> 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.  
> >   
> but if they are using dns64, the host will not have to create the
> address itself, so i am not sure how this relates to the hairpinning
> case we were mentioning before. I mean, afiau, the hairpinning case
> happens when the host is epxosed to the address directly.
> Whent he host receives the fqdn, this is just another normal
> communication where no need of hairpinning... am i missing something?

I see what you're saying now.  Yes, if the host has an AAAA record we would
not expect the administrator to point that AAAA record at the translator's
IPv6 address, but rather the administrator should point the AAAA at the host's
actual address.  With an AAAA record, the DNS64 function would return the AAAA
record (without synthesizing the response) so the communication -- when DNS64
was involved -- would be direct and not go through the translator.

> > 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.
> >
> >   
> 
> right, this is what i had in mind.

Ok.

-d

> Regards, marcelo
> 
> > -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
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/behave
> >>>>>>
> >>>>>>
> >>>>>>   
> >>>>>>         
> >>>>>>             
> >>>>> _______________________________________________
> >>>>> Behave mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/behave
> >>>>>
> >>>>>       
> >>>>>           
> >>>> _______________________________________________
> >>>> Behave mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/behave
> >>>>     
> >>>>         
> >>> _______________________________________________
> >>> Behave mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/behave
> >>>
> >>>   
> >>>       
> >> _______________________________________________
> >> Behave mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/behave
> >>
> >>     
> >
> >
> >   
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave
>