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

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

> On 2009-07-20 22:58, Chen Gang wrote:
> > 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.
> 
> 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.

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.

> 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.

-d