Re: [BEHAVE] Pref64 nature and referral support.

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

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Monday, February 23, 2009 5:55 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [BEHAVE] Pref64 nature and referral support.
> 
> Dan,
> 
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[e-mail]] 
> > Sent: Tuesday, February 24, 2009 9:51 AM
> > To: Miyata, Hiroshi ([e-mail]); [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: RE: [BEHAVE] Pref64 nature and referral support.
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Monday, February 23, 2009 4:34 PM
> > > To: [e-mail]; [e-mail]
> > > Cc: [e-mail]; [e-mail]; 
> [e-mail]
> > > Subject: RE: [BEHAVE] Pref64 nature and referral support.
> > > 
> > > Dan and Marcelo,
> > > 
> > > My suggestion is that we should not mix-up the two features of 
> > > well-known prefix.
> > > 
> > > As you know well-known prefix has two aspects.
> > > - Sythetic address identifier
> > > - Routable Prefix
> > > 	(Common prefix to lead the packets to the translators 
> > on somewhere)
> > > 
> > > The former aspect is useful, of course.
> > > The latter aspect is a bit dangerous that would cause 
> some problems.
> > > 	It  means some people outside my routing realm can 
> > > 	control the traffic to lead to a translator.
> > > 	The behavior may or may not fit my routing policy.
> > > 
> > > So, the routing information and identification should be 
> discussed 
> > > separately.
> > > 
> > > And I have another concern on well-known prefix.
> > > Is it routable prefix in global internet?  I don't believe so. ;-)
> > > 
> > > 
> > > 
> > > Comment on referrals.
> > > If a user in ISP-B contacts to SIP service of ISP-A and got 
> > synthetic 
> > > address with the local prefix of ISP-A, the user should send the 
> > > packet to the translator of ISP-A. Because the user is already 
> > > authorized by SIP service of  ISP-A directly or indirectly.
> > > Yes, ISP-A may charge for the traffic, but it is already accepted.
> > 
> > That would require some sort of interface between the ISP-A's 
> > NAT64 device and the its SIP proxy/B2BUA/SBC, in order to 
> > authorize the referral.  We could do that, I suppose.  
> > But 
> > what of referrals where some other ISP's SIP service is being 
> > utilized -- for example, Vonage?  In that case, Vonage's SIP 
> > proxies will not be able to tell ISP-A's NAT64 to allow the 
> > packets through.
> > 
> 
> Actually, my point is it works if the ISP designed to make it work.
> As you mentioned the interface definition is required in most case.
> So, I would like to say, this case can not be the reason to promote 
> well-known address.
> 
> To answer to your question, the asspmption come from original
> referral discussion with my understanding, maybe a long time ago.
> In most case SIP sevice would not work with deep cooperation.
> So, the case "referal works but traffic is dropped"
> unlikely happen in SIP service, I think.

That is the conclusion I believe I am reaching as I write the
I-D, too.

-d


> Sorry for your confusion.
> 
> Regards,
> 
> ....hiroshi miyata
> 
> 
> > > In general, I think the synthetic address builder(in this 
> > case ISP-A) 
> > > should take responsibility on the packet sent to the address.
> > > If ISP-A and ISP-B collaborate to integrate the translation 
> > service, 
> > > they may choose a common pref64 to optimize the traffic. In 
> > this case 
> > > both are taking the responsibility.
> > 
> > -d
> > 
> > > Best Regards,
> > > 
> > > ------------------------------------
> > > Hiroshi Miyata,
> > > Ubiquitous Field Computing Research Center, Corporate R&D 
> > Headquaters, 
> > > Yokogawa Electric Corp.
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Dan Wing
> > > > Sent: Tuesday, February 24, 2009 8:16 AM
> > > > To: 'marcelo bagnulo braun'
> > > > Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews'
> > > > Subject: Re: [BEHAVE] Pref64 nature and referral support.
> > > > 
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: [e-mail]
> > > > > [mailto:[e-mail]] On Behalf Of marcelo
> > > bagnulo braun
> > > > > Sent: Monday, February 23, 2009 2:19 PM
> > > > > To: Dan Wing
> > > > > Cc: 'Behave WG'; 'Jari Arkko'; 'Philip Matthews'
> > > > > Subject: Re: [BEHAVE] Pref64 nature and referral support.
> > > > > 
> > > > > Dan Wing escribió:
> > > > > >  
> > > > > >
> > > > > >   
> > > > > >> -----Original Message-----
> > > > > >> From: marcelo bagnulo braun [mailto:[e-mail]]
> > > > > >> Sent: Monday, February 23, 2009 12:44 PM
> > > > > >> To: Dan Wing
> > > > > >> Cc: 'Jari Arkko'; 'Behave WG'; 'Philip Matthews'
> > > > > >> Subject: Re: [BEHAVE] Pref64 nature and referral support.
> > > > > >>
> > > > > >> Dan Wing escribió:
> > > > > >>
> > > > > >>
> > > > > >>     
> > > > > >>>   
> > > > > >>>       
> > > > > >>>>>  Referring a
> > > > > >>>>> synthetic IPv6 address to an IPv6 host belonging to
> > > > another ISP
> > > > > >>>>> will not work (an ISP is unlikely to operate NAT64
> > > > devices for
> > > > > >>>>> the benefit of any IPv6 host on the Internet that
> > > > wants to use
> > > > > >>>>> it).
> > > > > >>>>>   
> > > > > >>>>>       
> > > > > >>>>>           
> > > > > >>>> but, if you use the well know prefix this owuld work,
> > > > cause the
> > > > > >>>> traffic would flow through the NAT64 located in each
> > > > ISP, right?
> > > > > >>>>     
> > > > > >>>>         
> > > > > >>> If that ISP operates a NAT64, yes.  So, referrals in
> > > that case
> > > > > >>> work once an ISP installs a NAT64 (or the subscriber
> > > > has some way
> > > > > >>> to use someone else's NAT64, perhaps via a tunnel and a
> > > > per-month
> > > > > >>> fee, for example).  But my point is that existing IPv6
> > > > hosts and
> > > > > >>> existing dual-stack hosts, in another ISP, cannot 
> utilize a 
> > > > > >>> synthetic address.
> > > > > >>>
> > > > > >>>   
> > > > > >>>       
> > > > > >> but that makes sense, right?
> > > > > >>
> > > > > >>
> > > > > >> I mean this stuff doesn't work when your IPv6 ISP
> > > > doesn't provide
> > > > > >> their customer with IPv4 Internet access (i.e it doesn't
> > > > provide a
> > > > > >> NAT64) and
> > > > > >> the cleint itself doesn't pay to any other NAT64 provider.
> > > > > >>
> > > > > >> So, if the client doesn't have access to the IPv4
> > > > > Internet, not only
> > > > > >> referrals to the IPv4 internet break, any communication
> > > > towards the
> > > > > >> IPv4 internet break, cause he is not paying for 
> that service
> > > > > >>     
> > > > > >
> > > > > > The same referral of a synthetic IPv6 address also 
> > breaks to a 
> > > > > > dual-stack host, until/unless that dual-stack host's ISP
> > > > operates a
> > > > > > NAT64.  And that will not make sense to someone operating a 
> > > > > > dual-stack host -- they will expect referrals to work
> > > > because they
> > > > > > are doing The Right Thing:  namely, operating a 
> > dual-stack host.
> > > > > >
> > > > > > I'll write this all up into an I-D which will hopefully
> > > make more
> > > > > > sense.
> > > > > >
> > > > > >   
> > > > > So, the case you are considering is:
> > > > > 
> > > > > Host A is IPv6-only
> > > > > Host B is dual stack
> > > > > Host C is IPv4-only
> > > > > 
> > > > > Host B is obtaining service from an IPv6-only ISP that has
> > > > not access
> > > > > to the IPv4 internet
> > > > 
> > > > No; Host B is dual-stack and fully-functioning (can 
> > access both the 
> > > > v6 and v4 Internet).  However, Host B's ISP has not installed a 
> > > > NAT64 device -- at least, not "yet".  Perhaps Host B's 
> ISP never 
> > > > will, because Host B's ISP believes that dual-stack 
> hosts are the 
> > > > right answer.  Perhaps Host B's ISP will only ever 
> > install a NAT44 
> > > > (in order to continue expanding their business after IPv4 
> > > > exhaustion).  Whatever the reason, Host B's ISP does not 
> > operate a 
> > > > NAT64.  Host B is running today's dual-stack OS (pick 
> > your favorite) 
> > > > and some
> > > > dual- stack capable stack.  If Host B (dual-stack) is 
> referred to 
> > > > the synthetic IPv6 address for Host C (IPv4-only), Host B 
> > can't do 
> > > > anything useful -- it cannot communicate with Host C.  
> "One Would 
> > > > Expect" that Host B could communicate with Host C, though -- 
> > > > afterall, both of them are accessible over IPv4.
> > > > 
> > > > Resolutions include:
> > > >   1. tell Host B to run new software that is aware of the
> > > >      synthetic prefix, and strip that synthetic prefix.
> > > >      This allows Host B to connect to Host C using IPv4.
> > > >   2. tell Host A to run new software that is aware of the
> > > >      synethric prefix, and strip that synthetic prefix
> > > >      before referring Host C's IPv4 address.  This allows
> > > >      Host B to connect to Host C using IPv4.
> > > > 
> > > > There is another interesting scenario, though, using 
> > another host, 
> > > > Host D with is IPv4 only.
> > > > 
> > > > If the referral is to Host D (IPv4 only), we cannot hope 
> > to refer an 
> > > > IPv6 address to Host D.  We can only successful refer an IPv4 
> > > > address to an IPv4 only host.
> > > > 
> > > > To my analysis, if we want referrals to work across a 
> > NAT64, we need 
> > > > to do (2), above -- namely, the host behind a NAT64 has 
> to remove 
> > > > the synthetic IPv6 address prior to referring the address.  
> > > > Otherwise as soon as an IPv6-only host behind a
> > > > NAT64 host sends a referral to either an IPv4-only host or to a 
> > > > dual-stack host, the referral fails.
> > > > 
> > > > 
> > > > I will write this up into an I-D.
> > > > 
> > > > -d
> > > > 
> > > > 
> > > > > Host A do get IPv6 Internet access through a translator
> > > > > 
> > > > > So, host A passes the IPv6 representation of Host C 
> > IPv4 address 
> > > > > to Host B.
> > > > > Host B could access to Host C if it used the IPv4 
> > address, but it 
> > > > > cannot reach host C using the IPv6 representation cause 
> > its ISP is 
> > > > > not providing NAT64 services, is that what you had in mind?
> > > > > 
> > > > > But, in this case, the Host B should be able to recognize,
> > > > if a well
> > > > > known prefix is used, that the IPv6 address it has 
> > received is an 
> > > > > IPv6 representation of an IPv4 address and use IPv4 
> connectivity
> > > > directly.
> > > > >
> > > > > I mean, the bottom line here, is that when you pass IPv6
> > > > address that
> > > > > represent IPv4 addresses around, the well know prefix seems
> > > > to behave
> > > > > much better, cause you can easily recognize that this is a 
> > > > > represenation of an IPv4 address
> > > > > 
> > > > > Regards, marcelo
> > > > > 
> > > > > 
> > > > > 
> > > > > > -d
> > > > > >
> > > > > >
> > > > > >   
> > > > > >> So, i think this is as much as he can for the money he
> > > > pays, right?
> > > > > >>
> > > > > >> In other words, this is not problem of the technology,
> > > > but it is a
> > > > > >> porblem of the clietn that is not buying the service
> > > > > >>
> > > > > >> Regards, marcelo
> > > > > >>
> > > > > >>
> > > > > >>     
> > > > > >>> -d
> > > > > >>>
> > > > > >>>
> > > > > >>>   
> > > > > >>>       
> > > > > >>>> regards, marcelo
> > > > > >>>>
> > > > > >>>>     
> > > > > >>>>         
> > > > > >>>>> I have more details written up on this topic and 
> > will write 
> > > > > >>>>> an I-D to present in San Francisco.
> > > > > >>>>>
> > > > > >>>>> -d
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>   
> > > > > >>>>>       
> > > > > >>>>>           
> > > > > >>>   
> > > > > >>>       
> > > > > >
> > > > > >
> > > > > >   
> > > > > 
> > > > > _______________________________________________
> > > > > Behave mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/behave
> > > > 
> > > > _______________________________________________
> > > > Behave mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/behave
> > > > =
> > 
> > =