Subject: [BEHAVE] RFC 5006

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 09:49:02 +0100

If RFC 5006 gained widespread usage, does anyone here see significant 
problems it would cause with DNS64 or any of the translation functions 
that use DNS?

There is a proposal on the table to move it from Experimental to 
Standards track status being discussed on the v6ops thread, and this 
question came up.

Offhand, I don't think there should be any problems, and 'behave' should 
resolve any if there are anyway given that RFC 5006 implementations 
already exist. But if there is a showstopper here, we should know about 
it now.

Thanks,

- Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Mar 2010 13:21:50 +0100

On 24 mrt 2010, at 9:49, Mark Townsley wrote:

> If RFC 5006 gained widespread usage, does anyone here see significant problems it would cause with DNS64 or any of the translation functions that use DNS?

Why would it?

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 13:33:17 +0100

>> If RFC 5006 gained widespread usage, does anyone here see significant problems it would cause with DNS64 or any of the translation functions that use DNS?

I don't think it would, but it came up. So, just askin'

- Mark

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Mar 2010 07:22:37 -0700

> problems it would cause with DNS64 or any of the translation functions

It sure would have made things much simpler for users of the ietf-nat64 
SSID.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Dave Thaler <[email-masked]>
Date: Wed, 24 Mar 2010 16:30:48 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Wednesday, March 24, 2010 7:23 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] RFC 5006
> 

And DHCPv6 (stateless) would have made things much simpler for users of
the ietf-nat64 SSID.

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 24 Mar 2010 10:33:50 -0700

> Standards track status being discussed on the v6ops thread, and this 

I have a 15 minute slot in 6man, later today, to propose that
6man take RFC5006 to standards-track.

> already exist. But if there is a showstopper here, we should 
> know about it now.

Yes, there is some impact on BEHAVE.

Boring Detail:

There are cases where DNS64 isn't used in the 'an IPv6 network
to the IPv4 Internet' scenario.  Such as, for example, an 
IPv4 address literal.  The only ways to fix this, that I see,
are application-specific proxies (for SIP, FTP, HTTP, etc.)
to deal with those cases, or for the host's IPv6 application 
to deal with those cases directly.  The application can 
deal with those cases directly as described in 
draft-wing-v6ops-v6app-v4server-01.txt.

Without that ability, IPv6-only hosts cannot use IPv4 address 
literals.  That means applications which always include IPv4 
address literals will break (e.g., RTSP, SIP, XMPP (voice/video 
chat), and so on).  Applications that sometimes include IPv4
address literals will also break (e.g., http://1.2.3.4).

In draft-wing-behave-learn-prefix, DNS and DHCPv6 are proposed
as mechanisms for a host (or its applications) to learn that
information, so they can synthesize their own address.

There is a desire to have draft-wing-behave-learn-prefix also
support RA.  However, due to the relative confusion around
using RA or using DHCPv6 for configuring important information
in a host, I removed RA from draft-wing-behave-learn-prefix.

Summary:

So, if RFC5006 goes forward as standards-track, I expect that 
I will revise draft-wing-behave-learn-prefix (again) to include
RA as a mechanism to learn the translator's prefix.

-d