Subject: [BEHAVE] Learning IPv6 translator's prefix - draft-wing-behave-learn-prefix-03

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Jul 2009 13:54:41 -0700

(posted as individual contributor.)

In many scenarios, the IPv6 translator needs to use a LIR prefix (that is, an
IPv6 prefix that belongs to the network operator) rather than a fixed,
well-known IANA-assigned prefix.  Much of the time, applications don't care
about the prefix of the IPv6 translator.  However, in some situations, IPv6
applications do need to know the translator's prefix so they can send packets
to the translator -- the best examples are applications that do not use DNS
(e.g., SIP and RTSP commonly use IPv4 addresses in SDP) or when using an IPv4
address literal (e.g., http://1.2.3.4).

draft-wing-behave-learn-prefix provides 3 mechanisms to learn the IPv6 prefix
of the IPv6/IPv4 translator:  DHCP, DNS, and IPv6 router advertisements.  It
also explains how DNSSEC can validate the prefix learned via those 3
mechanisms.  Please review the document with an eye towards how we might
reduce the number of mechanisms; I feel 3 is too many.

I will be presenting draft-wing-behave-learn-prefix-03 in Stockholm.

Thanks,
-d

---

From: Chen Gang <[email-masked]>
Date: Wed, 15 Jul 2009 18:52:43 +0800

Hello Dan,

I would like to clarify following points.

1. In NAT64, synthetic IPv6 address will be formed in DNS64 and back to IPv6
host. If I understand correctly, host will generate IPv6 destination address
combining with translator IPv6 prefix when IPv6 host initiate communication
with IPv4 host. Is it the scenario which could benefit from your solution?
2. In the RA approach, you have defiend new TLV type. What kind of LSA are
you used to transmit prefix information? How does the edge router identifies
IPv6 prefix information and transfer to hosts?

Thanks

Gang

2009/7/15 Dan Wing <[email-masked]>

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

-- 
陈刚
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Jul 2009 08:50:51 -0700

> -----Original Message-----
> From: Chen Gang [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 3:53 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] Learning IPv6 translator's prefix - 
> draft-wing-behave-learn-prefix-03
> 
> Hello Dan,
>  
> 1. In NAT64, synthetic IPv6 address will be formed in DNS64 
> and back to IPv6 host. If I understand correctly, host will 
> generate IPv6 destination address combining with translator 
> IPv6 prefix when IPv6 host initiate communication with IPv4 
> host. Is it the scenario which could benefit from your solution?

No.  That is a scenario that doesn't benefit from wing-behave-learn-prefix,
because the DNS64 does necessary work.

Rather, a scenario that would benefit from wing-behave-learn-prefix is (a) an
IPv6-only host, (b) behind a stateful or stateless IPv6/IPv4 translator, (c)
which is running an application that doesn't (or can't) do a DNS AAAA query of
the hostname.  If it cannot do an AAAA query, the DNS64 cannot provide its
mapping to the host.

For example, if the user on such a host types in a URI with an IPv4 address
literal "http://1.2.3.4", and the web browser implements
wing-behave-learn-prefix, the web browser could send a TCP SYN to Pref64::1.2.
3.4, which will be routed to the IPv6/IPv4 translator, translated to the IPv4
address 1.2.3.4, and sent to the server on the Internet.  

Other examples are listed in the introduction,

   o  host-based DNSSEC validation (Section 4.3 of
      [I-D.bagnulo-behave-dns64])

   o  BitTorrent (Section 2.2 of [I-D.wing-behave-nat64-referrals])

   o  multicast translation ([I-D.venaas-behave-v4v6mc-framework] and
      Section 4 of [I-D.venaas-behave-mcast46])

   o  URI schemes with host IPv4 address literals rather than domain
      names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1,
      ipp://192.0.2.1)).

> 2. In the RA approach, you have defiend new TLV type. What 
> kind of LSA are you used to transmit prefix information? How 
> does the edge router identifies IPv6 prefix information and 
> transfer to hosts?

My co-authors wrote the RA section so I will defer to them.

-d

> 	address literal (e.g., http://1.2.3.4 <http://1.2.3.4/> ).
>

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 16 Jul 2009 09:25:23 +0800

> kind of LSA 
> > are you used to transmit prefix information? How does the 
> edge router 
> > identifies IPv6 prefix information and transfer to hosts?
> 
  
Hi Gang,

Opaque LSA defined in [RFC5250] should be used. As stated in RFC5250, "the
information contained in Opaque LSAs may be used directly by OSPF or
indirectly by some application wishing to distribute information throughout
the OSPF domain".

Xiaohu

> > 	In many scenarios, the IPv6 translator needs to use a 
> LIR prefix 
> > (that is, an
> > 	well-known IANA-assigned prefix.  Much of the time, 
> applications 
> > don't care
> > 	applications do need to know the translator's prefix so 
> they can send 
> > packets
> > 	to the translator -- the best examples are applications 
> that do not 
> > use DNS
> > 	(e.g., SIP and RTSP commonly use IPv4 addresses in SDP) 
> or when using 
> > an IPv4
> > 	draft-wing-behave-learn-prefix provides 3 mechanisms to 
> learn the 
> > IPv6 prefix
> > 	mechanisms.  Please review the document with an eye 
> towards how we 
> > might

---

From: Chen Gang <[email-masked]>
Date: Mon, 20 Jul 2009 00:43:24 +0800

Hello Dan,

Thanks for discussion. My reply is inline.
2009/7/15 Dan Wing <[email-masked]>

> address 1.2.3.4, and sent to the server on the Internet.

==>I guess my understanding is aligned with your explanations. The scenario
could be that an IPv6 host know peer’s IPv4 address in advance (i.e. "
http://1.2.3.4") without doing DNS query. In order to let data packets go
through the IPv6/IPv4 translator, the host will generate IPv6 destination
address combining with translator IPv6 prefix (i.e. "Pref64::1.2"). If that
is the scenario you have clarified, I would like to dig-up something from
that. I guess the application running on IPv6 host should be IPv4-based,
because only IPv4 application can identify an IPv4 address inputs. In that
case, more accurately, the scenario is an IPv4 application in IPv6 host to
call IPv4 application in an IPv4 host through IPv4/IPv6 translator. We also
have done some works on this scenario.

>      names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1,

==> case 4 is the scenario we would like to focus.

> My co-authors wrote the RA section so I will defer to them.

==>Thanks for information.

> > LIR prefix (that is, an
> > applications don't care
> > they can send packets
> > that do not use DNS
> > or when using an IPv4
> > learn the IPv6 prefix
> > towards how we might

-- 
陈刚
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 19 Jul 2009 09:54:25 -0700

> Sent: Sunday, July 19, 2009 9:43 AM
> To: Dan Wing
> 	> Cc: [email-masked]; 
> [email-masked]
> 	literal "http://1.2.3.4 <http://1.2.3.4/> ", and the 
> web browser implements
> ==>I guess my understanding is aligned with your 
> explanations. The scenario could be that an IPv6 host know 
> peer’s IPv4 address in advance (i.e. "http://1.2.3.4 
> <http://1.2.3.4/> ") without doing DNS query. In order to let 
> data packets go through the IPv6/IPv4 translator, the host 
> will generate IPv6 destination address combining with 
> translator IPv6 prefix (i.e. "Pref64::1.2"). If that is the 
> scenario you have clarified, I would like to dig-up something 
> from that. I guess the application running on IPv6 host 
> should be IPv4-based, because only IPv4 application can 
> identify an IPv4 address inputs. In that case, more 
> accurately, the scenario is an IPv4 application in IPv6 host 
> to call IPv4 application in an IPv4 host through IPv4/IPv6 
> translator. 

I suppose that is another way to describe the application.  Almost all
applications, today, understand IPv4 and IPv4 address literals.  I doubt that
code will be stripped when the applications add IPv6 support - they will still
retain the ability and understanding to understand IPv4 address literals.  If
the host only gets an IPv6 address, I don't know what we would call the
application:  it understands both IPv4 and IPv6.  But it can only successfully
send IPv6 packets on its IPv6 interface.  Creating some terminology would be
helpful.

-d

> We also have done some works on this scenario. 
> 
> 	
> 	
> 	  o  multicast translation 
> ([I-D.venaas-behave-v4v6mc-framework] and
> 	     names (e.g., http://192.0.2.1 <http://192.0.2.1/> 
> , ftp://192.0.2.1 <ftp://192.0.2.1/> , imap://192.0.2.1 
> <http://192.0.2.1/> ,
> 	     ipp://192.0.2.1 <http://192.0.2.1/> )).
> 
>  
> 	>       address literal (e.g., http://1.2.3.4 
> <http://1.2.3.4/>  <http://1.2.3.4/> ).
> 	
> 	>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 19 Jul 2009 19:12:47 +0200

> reduce the number of mechanisms; I feel 3 is too many.

I worry about deployability. The way I see it, it is de facto  
impossible to deploy new DHCPv6 or RA options. The reason for this is  
that on the client, in most cases (i.e., Windows and MacOS), the code  
that interprets these options is deep inside the OS, and can only  
really be modified by the OS vendor. In the case of RAs, the same is  
true on the server/router side. (See RFC 5006 deployment.)

The DNS option redirects to another document that redirects to another  
document (please resolve the recursion in the draft!) that describes a  
new DNS resource record. These are also notoriously hard to deploy.

So what I would suggest:

- forget about RAs
- forget about DHCP to talk to the clients, but this could be useful  
to talk to home gateways if they were to implement well-known prefix  
to non-well-known prefix translation
- change the DNS mechanism to use existing RRs

---

From: Chen Gang <[email-masked]>
Date: Mon, 20 Jul 2009 13:53:35 +0800

Hi Dan,

Please see my reply inline.

2009/7/20 Dan Wing <[email-masked]>

> send IPv6 packets on its IPv6 interface.  Creating some terminology would

==>I guess this sort of application we can call them as "upgraded IPv4
application". But I doubt that not all of IPv4 application will be able to
upgrade,since there still are numerous conventional IPv4 applications. Why
don't you put some scenairos, which are siminlar with BIA or BIS, into your
beneficial example list? It can understand IPv4 address literals and can
sucessfully send IPv6 packets on its IPv6 interface.

Thanks for the discussion.

-Gang

-- 
陈刚
[email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 09:54:37 +0200

On 20 jul 2009, at 7:53, Chen Gang wrote:

> Why don't you put some scenairos, which are siminlar with BIA or  
> BIS, into your beneficial example list? It can understand IPv4  
> address literals and can sucessfully send IPv6 packets on its IPv6  
> interface.

As I've been saying for a long time, NAT64 and DS-light are the same  
thing as far as the translator is concerned except that DS-light  
carries an IPv4 header that the translator doesn't need. (I guess the  
fragmentation issues are a bit simpler.)

On the client side, it is of course trivial to implement an API shim  
that takes API calls that would normally generate IPv4 packets but now  
generate IPv6 packets, as long as the prefix is known so a full IPv6  
address can be generated, which will get the packet routed to the  
translator.

On the other hand, I don't think applications like Skype are ever  
going to work over IPv6 until they actually build in IPv6 support.

---

From: Chen Gang <[email-masked]>
Date: Mon, 20 Jul 2009 18:58:34 +0800

I guess that my point hasn't been clarified enough,

What I am saying is that NAT64 draft is based on the Ipv6 only host,
But the question here is how could "http://1.2.3.4" be processed by network
stack,
will IPv4 socket api be called or will IPv6 socket api be called.
If that is the case, maybe this draft could find some scenario like china
mobile proposed
PNAT64 scenario.

In addition, there are two points need to be elaborated.

[Point A]How could IPv6 host form an IPv6 address depending on the IPv4
address inputs?  I suggest to add one section to describe the host-based
translator processing.The host could be done through socket API
translation module or packet translation module.

[Point B]How could the IPv6 host get peer's IPv4 address?  if it is an
assumption that user can get IPv4 in advance or can remember peer's IPv4
address, that is an rare occurrence. Hereby, I suggest to add another
section to explain the case, in which IPv6 host will initiate both A and
AAAA DNS query to a dual-stack DNS server located in IPv6. However, only an
A record reply has been received by IPv6 host.

Thanks for the discussion

-Gang

2009/7/20 Iljitsch van Beijnum <[email-masked]>

> Why don't you put some scenairos, which are siminlar with BIA or BIS, into
>> your beneficial example list? It can understand IPv4 address literals and
>> can sucessfully send IPv6 packets on its IPv6 interface.
>>
>
> As I've been saying for a long time, NAT64 and DS-light are the same thing
> as far as the translator is concerned except that DS-light carries an IPv4
> header that the translator doesn't need. (I guess the fragmentation issues
> are a bit simpler.)
>
> On the client side, it is of course trivial to implement an API shim that
> takes API calls that would normally generate IPv4 packets but now generate
> IPv6 packets, as long as the prefix is known so a full IPv6 address can be
> generated, which will get the packet routed to the translator.
>
> On the other hand, I don't think applications like Skype are ever going to
> work over IPv6 until they actually build in IPv6 support.
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 14:31:15 +0200

On 20 jul 2009, at 12:58, Chen Gang wrote:

> But the question here is how could "http://1.2.3.4" be processed by  
> network stack,

Depends on the API calls the application performs. A dual stack  
application would probably use getaddrinfo() or a similar call. Which  
would then return ::ffff:102:304. Then, trying to communicate  
with ::ffff:102:304 will normally trigger the generation of IPv4  
packets.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 20 Jul 2009 15:41:09 +0300

> with ::ffff:102:304 will normally trigger the generation of IPv4

Or it is IPv4-only, or has IPv4-specific code. Then it will use normal INET 
sockets. Either way, if you want IPv4 applications to work on an IPv6-only 
host, you need a virtual IPv4 stack in the host operating system.

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

---

From: Hui Deng <[email-masked]>
Date: Mon, 20 Jul 2009 21:03:07 +0800

This is exactly the China Mobile's proposal, we need PNAT inside the host
to make conventional IPv4 application to work

-Hui

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 20 Jul 2009 15:03:37 +0200

> host, you need a virtual IPv4 stack in the host operating system.

I don't think a virtual IPv4 stack is needed, but I'd know for sure if  
you explained what it is.

A bump-in-the-API technique like I (and others) described would make  
98% of the IPv4 applications work. This is all quite trivial except  
that you need to know the NAT64 prefix in the case that prefix isn't  
well-known.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 20 Jul 2009 16:20:04 +0300

> you explained what it is.

You need to support INET sockets, at the API level. It can be made with a real 
set of IPv4 transport and the network layers, running on top of a virtual link 
layer. Or you can translate to INET6 sockets internally and use an IPv6 stack.

> that you need to know the NAT64 prefix in the case that prefix isn't

98% might be optimistic, but yes. Most will work. Especially TCP will work.

---

From: Hui Deng <[email-masked]>
Date: Mon, 20 Jul 2009 21:51:22 +0800

Albert,

Thanks for your discussion, reply inline

2009/7/20  <[email-masked]>:
>
> Hui,
>
> Is the idea work like this？
>
> keep existnig ipv4 application in end user box run as usual, and use the
> translation function block to bridge user environment to IPv6 network
> environment?
==> In the host, yes,

> Reason is ipv4 to ipv6 transition will be triggered by the depletion of end
> user ip address
> but os app vendors have no incentive to move to ipv6,
==> This is what we learned from our service network, I guess T-Mobile USA
has expressed similar concern in other thread.

> so the design is to
> keep user ipv4 app envment untouched,
> but assign user ipv6 address from network/operators perspective,
> while let the combination work,
==>  Yes, and we plan to assign both IPv6 prefix and IPv4 address
(either public or private)

Regards,

-Hui

>
>
>
> Regards,
> Albert
>
>
>
>
>
> Hui Deng <[email-masked]>
> 发件人:  [email-masked]
>
> 2009-07-20 21:03
>
> 收件人
> Rémi Denis-Courmont <[email-masked]>
> 抄送
> [email-masked], Dan Wing <[email-masked]>, Chen Gang <[email-masked]>
> 主题
> Re: [BEHAVE] Learning IPv6 translator's prefix -
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Jul 2009 08:40:37 -0700

> Sent: Monday, July 20, 2009 3:59 AM
> To: Iljitsch van Beijnum
> Cc: Dan Wing; Behave WG
> But the question here is how could "http://1.2.3.4 
> <http://1.2.3.4/> " be processed by network stack, 
> If that is the case, maybe this draft could find some 
> scenario like china mobile proposed
> PNAT64 scenario.
>  
> [Point A]How could IPv6 host form an IPv6 address depending 
> on the IPv4 address inputs?  I suggest to add one section to 
> describe the host-based translator processing.The host could 
> be done through socket API translation module or packet 
> translation module.
>  
> [Point B]How could the IPv6 host get peer's IPv4 address?  if 
> it is an assumption that user can get IPv4 in advance or can 
> remember peer's IPv4 address, that is an rare occurrence. 

By typing it in, by getting an HTTP referral (e.g., Google's 
cache uses native IPv4 and native IPv6 addresses), via SDP
(SIP and RTSP use SDP; common deployments of SIP and RTSP use
IPv4 address literals).  I provided a list in 
draft-wing-behave-learn-prefix.

> Hereby, I suggest to add another section to explain the case, 
> in which IPv6 host will initiate both A and AAAA DNS query to 
> a dual-stack DNS server located in IPv6. However, only an A 
> record reply has been received by IPv6 host. 

I don't understand.  If there is an IPv4 address literal, there 
is no interaction with DNS.

-d

> 		Why don't you put some scenairos, which are 
> siminlar with BIA or BIS, into your beneficial example list? 
> It can understand IPv4 address literals and can sucessfully 
> send IPv6 packets on its IPv6 interface.
> 		
> 
> 
> 	As I've been saying for a long time, NAT64 and DS-light 
> are the same thing as far as the translator is concerned 
> except that DS-light carries an IPv4 header that the 
> translator doesn't need. (I guess the fragmentation issues 
> are a bit simpler.)
> 	
> 	On the client side, it is of course trivial to 
> implement an API shim that takes API calls that would 
> normally generate IPv4 packets but now generate IPv6 packets, 
> as long as the prefix is known so a full IPv6 address can be 
> 	On the other hand, I don't think applications like 
> Skype are ever going to work over IPv6 until they actually 
> build in IPv6 support.
> 	
> 
> 
> 
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Jul 2009 08:48:38 -0700

> From: Hui Deng [mailto:[email-masked]] 
> Sent: Monday, July 20, 2009 6:03 AM
> To: Rémi Denis-Courmont
> Cc: [email-masked]; Dan Wing; Chen Gang
> This is exactly the China Mobile's proposal, we need PNAT 
> inside the host to make conventional IPv4 application to work

I would really like to understand how draft-huang-pnat-host-ipv6
differs from what Iljitsch and Remi were describing in
http://www.ietf.org/mail-archive/web/behave/current/msg06270.html
and 
http://www.ietf.org/mail-archive/web/behave/current/msg06271.html,
where Remi wrote:

:
:  Iljitsch wrote:
:  > I don't think a virtual IPv4 stack is needed, but I'd know for sure 
:  > if you explained what it is.
:
:  You need to support INET sockets, at the API level. It can be made 
:  with a real set of IPv4 transport and the network layers, running 
:  on top of a virtual link layer. Or you can translate to INET6 sockets 
:  internally and use an IPv6 stack.
:
:  > A bump-in-the-API technique like I (and others) described would make
:  > 98% of the IPv4 applications work. This is all quite trivial except
:  > that you need to know the NAT64 prefix in the case that prefix isn't
:  > well-known.
:
:  98% might be optimistic, but yes. Most will work. Especially TCP 
:  will work.
:

-d

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Jul 2009 08:46:55 -0700 (PDT)

--- On Mon, 7/20/09, Hui Deng <[email-masked]> wrote:

> From: Hui Deng <[email-masked]>
> Subject: Re: [BEHAVE] Learning IPv6 translator's prefix - draft-wing-behave-learn-prefix-03
> To: [email-masked]
> Cc: [email-masked], [email-masked], "Dan Wing" <[email-masked]>, "Chen Gang" <[email-masked]>
> Date: Monday, July 20, 2009, 9:51 AM
> Albert,
> 

Just talking smartphons, MIDs, and the like, there are not millions of applications. There are a select few protocols, and in many places the operator / service controller has a fair amount of control of what these applications are and how they behave (think iPhone applications getting pulled). Look at any ISP's / mobile providers traffic profile and it is 95+% HTTP / HTTPS / SMTP and other well know protocols that behave fairly well with NAT.
> has expressed similar concern in other thread.

For mobiles, once again the operator has some control.  Please look at the publicly available (requires free account) specification for 4G LTE handset from Verizon.  Verizon is a first mover and they are shaping the landscape.

https://www22.verizon.com/opendev/Forum/LTE_Document_Archives.aspx

"The device shall support IPv6. The device may support IPv4. IPv6 and IPv4 support shall be per the 3GPP Release 8 Specifications (March 2009)". (section 3.2.4.1)

and

"The device shall be assigned an IPv6 address whenever it attaches to the LTE network." (section 3.2.4.2)

IPv4 support appears optional: "If the device supports IPv4, then the device shall be able to support simultaneous IPv6 and IPv4 sessions." (section 3.2.4.4) 

This is where the world is going.  Now, with NAT64 we can reduce the need for the mobile to require IPv4.  Will some apps require v4 indefinitely? yes. Will they get IPv4 service, perhaps at a higher price?  Yes.  Will that be the mass market or 1% of people.  It will be 1%, and it may be a "business class" service.

> (either public or private)

Too much work for a minority of the customers, most traffic is HTTP via NAT44 today, it will change to being HTTP over NAT64 ... my customers will never know or care that i moved from ipv4 to ipv6.  And, that is how we know we did our job right.

> > [email-masked],
> Dan Wing <[email-masked]>,
> Chen Gang <[email-masked]>
> > 主题
> >> Or it is IPv4-only, or has IPv4-specific code.
> Then it will use normal
> >> INET
> > ZTE Information Security Notice: The information
> contained in this mail is solely property of the sender's
> organization. This mail communication is confidential.
> Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this
> communication to others.
> > This email and any files transmitted with it are
> confidential and intended solely for the use of the
> individual or entity to whom they are addressed. If you have
> received this email in error please notify the originator of
> the message. Any views expressed in this message are those
> of the individual sender.

---

From: [email-masked]
Date: Mon, 20 Jul 2009 21:14:19 +0800

Hui,

Reason is ipv4 to ipv6 transition will be triggered by the depletion of 
end user ip address
but os app vendors have no incentive to move to ipv6,

so the design is to 

Regards, 
Albert

收件人

-Hui

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Jul 2009 12:13:57 +1200

> will IPv4 socket api be called or will IPv6 socket api be called.

Firstly, should we really be spending effort on this problem? What's
wrong with an error response to the user? Address literals are supposed
to be for diagnostic use only. "No IPv4 available" would be an appropriate
diagnostic message.

Secondly, as others have observed, RFC3338 documented a solution 7
years ago, to which we need to add a way to determine the correct
v6 prefix to use. The same goes for RFC2767.

    Brian

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Jul 2009 17:54:56 -0700

> > But the question here is how could "http://1.2.3.4" be 
> > processed by network stack,
> to be for diagnostic use only. "No IPv4 available" would be 
> an appropriate diagnostic message.

IPv4 address literals in URLs are an obvious use of IPv4 address
literals, but I agree they are the most likely to resolve themselves.
As recently as last month I was still seeing IPv4 address literals as 
results from various search engines; if I was IPv6-only and I lacked
BIA (RFC3338) or BIS (RFC2767), I would be out of luck.  We do need
*some* way of solving that.  Perhaps, as I believe you are suggesting,
the solution is "do BIA" or "do BIS", rather than encouraging solving
the problem in the application.

There are other applications that commonly use IPv4 address literals.
SIP and RTSP use IPv4 address literals almost exclusively in their
SDP (which describes the IP addresses and ports for the media path).
For those protocols, it makes little sense to rely on DNS to say
128-7-8-9.comcast.net rather than just 128.7.8.9.  I believe XMPP
works similarly and uses IPv4 address literals.

-d

---

From: Hui Deng <[email-masked]>
Date: Tue, 21 Jul 2009 22:54:03 +0800

Albert,

Inline please,

2009/7/20  <[email-masked]>:
>
>
> Hui,
>
> How do u think of my following idea:
>
> end user actually will not consume any ipv4 resource cuz lack of ipv4 is the
> trigger for this design. if they still use ipv4, it's a paradox/contradict.
==> If the service network based on public ipv4 address, I don't see
lacking of private ipv4 address issue.

>
> end user can use any ipv4 addr as they/operators like, which means operators
> do no need to manageme ipv4 part of end user
==> not very clear, but it doesn't matter.

>
> end user is tricked into thinking they are talking with other ipv4 hosts,
> but acctually there are no ipv4 packet in operators network, all operator
> get are ipv6 packets, the middle box helps to translate end user v4 packet
> to network v6 packet and do the tricking job.
==> this description is not clear for me, could u help to explain DNS firstly.
and where is the middle box, in the host or in the network,

>
> end user can use duplicate ipv4 address and can talk to other end user with
> duplicate ipv4 addr with the help of man-in-the-middle box
==> not clear to me, let's find time to talk face to face.

-Hui

> ...............
> 2009-07-20 21:51
> [email-masked]
> [email-masked], [email-masked], Dan Wing <[email-masked]>, Chen
> Gang <[email-masked]>, Rémi Denis-Courmont
> <[email-masked]>
> 主题
> Re: Re: [BEHAVE] Learning IPv6 translator's prefix -
>> end
>> ZTE Information Security Notice: The information contained in this mail is
>> solely property of the sender's organization. This mail communication is
>> confidential. Recipients named above are obligated to maintain secrecy and
>> are not permitted to disclose the contents of this communication to others.
>> This email and any files transmitted with it are confidential and intended
>> solely for the use of the individual or entity to whom they are addressed.
>> If you have received this email in error please notify the originator of the
>> message. Any views expressed in this message are those of the individual
>> sender.

---

From: Hui Deng <[email-masked]>
Date: Tue, 21 Jul 2009 23:58:56 +0800

Please allow me to snip for easily readable.

> Just talking smartphons, MIDs, and the like, there are not millions of applications. There are a select few protocols, and in many places the operator / service controller has a fair amount of cont…
==> Apple this month birthday App store said that there are 65,000
applications already.
I guess lots of them will not use seletive protocols only.
it estimates 100,000 by the end of the year 2009, 10 million apps in 2020
we may not necessraily believe it or not, but anyhow, the mobile
device is not designed for today,
it may have to be used by 2010, or some one will still use it by 2011.

> This is where the world is going.  Now, with NAT64 we can reduce the need for the mobile to require IPv4.  Will some apps require v4 indefinitely? yes. Will they get IPv4 service, perhaps at a high…
==> Firstly expecting that Verizon engineer in this mailing list could
also standing out and make some defence.
if not, we will try to ping Verizon SA2 delegate and see what exact it means.
Just give a quick reading about those statement, personally, I don't
feel it is really clear for me,
Since one mobile support IPv6, it normally has 3 level meaning, but
normally, they only support level 1 IPv6 ability.
Section 3.2.2.4 is already supported by rel.8 from this May, but it
seems March still need two PDP contexts.
As we talked in other email, IPv6/IPv4 support has multiple meanings,
Dave also presented in the intermedium meeting.
so those statement are not very clear fo rme.
Honestly speaking, if you are saying IPv4 service is business class
service, this really don't convince me.

> Too much work for a minority of the customers, most traffic is HTTP via NAT44 today, it will change to being HTTP over NAT64 ... my customers will never know or care that i moved from ipv4 to ipv6.…
==> If you are only solveing the problem of HTTP, I guess private IPv4
addres already enough,
so I guess you are not only doing that, but also something else.

Thanks for the discussion.
Looking forward to face to face talking.

Best regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Wed, 22 Jul 2009 00:32:06 +0800

Hi,

I guess Iljitsch is explaning the v4 socket api is still needed,
whether it will be called virtual v4 stack, it dosn't matter,

Regarding to difference between PNAT and BIA/BIS, anyhow, we are also
upgrading it.
1) Mapping table is not needed for v4-v4 over IPv6 network
communication for PNAT, but BIA still need it.
2) BIA always provide the host the faked IPv4 address, it need ALG in
the NAT64 side at least.
3) PNAT described in detail how it work together with PNAT64, BIA/BIS doesn't
4) PNAT has described mulltiple scenario, but BIA/BIS doesn't.

thanks for hte disucssion.

-Hui

---

From: Chen Gang <[email-masked]>
Date: Wed, 22 Jul 2009 01:37:40 +0800

Hello Dan,

2009/7/21 Dan Wing <[email-masked]>

> the problem in the application.

=> "do BIA", "do BIS" and "upgrading applicaiton" are three ways to resolve
the problems.
But there is not enough incentive to upgrade existing IPv4 applications. For
host stack, it could be possible to be modified to accomodate IPv4
applicaition when operators strat to customize user's terminals. Therefore,
the probability of  convitional IPv4 app on a "upgraded IPv6 host"  might be
higher than "upgraded IPv4 application" on a normal IPv6 host.

I would like to propose one more application which can benefit knowing the
IPv6 prefix:
   ....
*   o  A conventional IPv4 applciation installed on a IPv6 host, on which
host-based translator functionalities are performed to make IPv4 application
accomodate IPv6 stack.*

BRs

Chen Gang

-- 
陈刚
[email-masked]

---

From: Anthony Roberts <[email-masked]>
Date: Wed, 22 Jul 2009 08:35:02 -0600

Hi Brian,

With respect to BIS/BIA, adding a way to discover the prefix will not
prevent application developers from implementing their own workarounds when
needed to run on operating systems that don't yet support this. In the
absence of a better alternative, developers will resort to discovering the
prefix themselves via DNS and synthesizing addresses within their
application.

At a minimum it seems prudent to specify the circumstances when
applications may attempt discovery/synthesis. It would also be possible to
extend the DNS64 to provide AAAA records with names based on IPv4 literals
in a well known .arpa DNS zone; that would at least contain address
synthesis to one of the places it already has to exist.

Regards,

-Anthony

On Tue, 21 Jul 2009 12:13:57 +1200, Brian E Carpenter
<[email-masked]> wrote:
>> network

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Jul 2009 09:02:38 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anthony Roberts
> Sent: Wednesday, July 22, 2009 7:35 AM
> To: Brian E Carpenter
> Cc: Behave WG; Dan Wing; Chen Gang

Sure.

> applications may attempt discovery/synthesis.

That implies the application can determine if the underlying IP stack
does, or doesn't, have BIS/BIA and translation built in.  Or can 
determine if that underlying support is (somehow) inadequate (e.g.,
buggy or has known incompatibilities with whatever the application
needs).

> It would also be possible to

Not sure what you mean - can you provide an example or explain it
differently?  I'm stuck on "names based on IPv4 literals".

-d

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 22 Jul 2009 16:01:48 -0400

Hi Hui,

Can you include a session in your draft to compare BIA/BIS to SNAT?

Thanks,
Yiu

---

From: Hui Deng <[email-masked]>
Date: Thu, 23 Jul 2009 07:28:45 +0800

Ok, thanks for your good suggestion.

Regards,

-Hui