Subject: Re: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest

From: Cameron Byrne <[email-masked]>
Date: Thu, 12 Apr 2012 18:42:46 -0700

Hi all,

We are preparing to publish the next revision of 464XLAT as BCP

2 questions:

1.  BCP OK as Fred suggested?  Or informational?

2.  Any other changes aside from the ones listed below?

Thanks!

CB

PS:  Easy button to the draft ->
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
PPS:  Hopefully useful info on how you too can try 464XLAT, as well as
test results, https://sites.google.com/site/tmoipv6/464xlat

On Wed, Mar 28, 2012 at 3:01 PM, Cameron Byrne <[email-masked]> wrote:
> Folks,
>
> For the sake of clarity, what i understand from Fred's email, and has
> been supported by 3 people so far, is that there is desire to move
> from informational to BCP and some changes are required along the way.
>
> I believe these specific changes are required from my reading of
> Fred's mail, let me know if something is missing:
>
> 1. Change document category from informational to BCP
>
> 2.  Re-insert RFC 2119 keywords
>
> 3. Replace all text in section in 6.1 with this one sentence "The XLAT
> Prefix format used on the CLAT for RFC6145 translation  is defined in
>   Section 2.2 of [RFC6052]. "  Also, remove all references to /96 in
> section 6.5.  Update diagram in 6.2 to remove /96.
>
> 4.  The DNS proxy section will add a reference to RFC5625, such as
> adding the sentence to the beginning of section 6.4 stating "The CLAT
> SHOULD implement a DNS proxy as defined in RFC 5625."
>
> Am I missing something?
>
> Are these the agreeable terms of moving forward with 464XLAT as a BCP
> instead of informational?
>
> Thanks for the feedback and helping to clarify the path forward
>
> Cameron

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Apr 2012 11:31:55 +0900

> 2.  Any other changes aside from the ones listed below?

Why do we need to say anything about DNS proxying? I thought the
controversy around proxying was about for neighbour discovery proxying, not
DNS proxying.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 12 Apr 2012 20:19:02 -0700

On Thu, Apr 12, 2012 at 7:31 PM, Lorenzo Colitti <[email-masked]> wrote:
> Why do we need to say anything about DNS proxying? I thought the controversy
> around proxying was about for neighbour discovery proxying, not DNS
> proxying.

There have been several mails about DNS proxy as well as claiming IPv6
addresses for sourcing CLAT RFC 6145 translations.

I believe the draft in its current form makes it clear that neither
are mandatory, but they both provide utility in certain circumstances.

DNS Proxy -- http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.4

We suggest that CLAT proxy DNS to make the DNS transaction native IPv6
from the CLAT and avoid stateful translation of every DNS query on the
PLAT. But, double translation of client IPv4 DNS queries to an
arbitrary IPv4 DNS server is supported.  The change log reflects
adding a reference to RFC5625

Prefix handing --http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5

Multiple methods are defined, including doing NAT446 on the CLAT so
that all LAN IPv4 flows are NAT44 to a single IPv4 address, then that
single IPv4 address is mapped to single IPv6 source address.

Is there something specific that needs to be added or deleted from the
current draft or change log?

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Apr 2012 12:47:56 +0900

On Fri, Apr 13, 2012 at 12:19, Cameron Byrne <[email-masked]> wrote:

> We suggest that CLAT proxy DNS to make the DNS transaction native
> IPv6 from the CLAT and avoid stateful translation of every DNS query on the
> PLAT.

I think this is not controversial, because you don't need to define any new
behaviour. You simply run a DNS forwarder on the CLAT. Was there objection
to stating this as being optional but recommended?

Prefix handing --
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5
>

I think the "take ownership of a /96" text was controversial. I believe the
objection is as follows:

- If you claim a /96 on the link, you have to ensure that DAD fails for
addresses in that /96. This behaviour is not specified anywhere, and the
operational implications (e.g., the possibility of other hosts giving up
because every address they try is taken) are not considered anywhere.
- The reason why this document is in v6ops is that it does not define any
new behaviour, but only how to cobble together existing behaviour to
achieve a useful result.
- v6ops cannot define new behaviour; that belongs elsewhere

So if you want to keep this in the draft, you have to specify how to do it
(probably in 6man) and possibly write up the operational implications (here
in v6ops).

And of course, you also have to implement it, and it's much more complex to
implement than simply using a /128.

I think that if you're in a hurry to get this document through the process,
you should just remove the /112 mode from the draft completely. I don't see
it as being particularly useful either. What can you do with the /112 mode
that you can't do with a NAT44 on the CLAT? If the use case is a mobile
device, then they implement NAT44 anyway.

If you want to provide "better quality" IPv4 access to nodes behind the
CLAT, then my personal opinion is not to use 464xlat at all. 464xlat is
already little better than IPv4 over carrier pigeon, and if you want high
quality, you're better off using one of the higher-quality mechanisms being
worked on in softwires.

Cheers,
Lorenzo

---

From: Ole Trøan <[email-masked]>
Date: Fri, 13 Apr 2012 09:42:17 +0200

> - If you claim a /96 on the link, you have to ensure that DAD fails for addresses in that /96. This behaviour is not specified anywhere, and the operational implications (e.g., the possibility of other hosts giving up because every address they try is taken) are not considered anywhere.
> - The reason why this document is in v6ops is that it does not define any new behaviour, but only how to cobble together existing behaviour to achieve a useful result.
> So if you want to keep this in the draft, you have to specify how to do it (probably in 6man) and possibly write up the operational implications (here in v6ops).
> 
> And of course, you also have to implement it, and it's much more complex to implement than simply using a /128.
> 
> I think that if you're in a hurry to get this document through the process, you should just remove the /112 mode from the draft completely. I don't see it as being particularly useful either. What can you do with the /112 mode that you can't do with a NAT44 on the CLAT? If the use case is a mobile device, then they implement NAT44 anyway.
> 
> If you want to provide "better quality" IPv4 access to nodes behind the CLAT, then my personal opinion is not to use 464xlat at all. 464xlat is already little better than IPv4 over carrier pigeon, and if you want high quality, you're better off using one of the higher-quality mechanisms being worked on in softwires.

I think you could define two modes here.
1) use a single IPv6 address for the translation
2) reserve a full /64 for the purpose of translation

cheers,
Ole

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 13 Apr 2012 10:38:48 -0500

> 2) reserve a full /64 for the purpose of translation

This is actually what RFC 6052 is also recommending:

When the prefix is 64 bits long, the IPv4 address is encoded in
      positions 72 to 103.

6052 also allows the well-known prefix which is /96 but no one is supporting it.

Behcet

---

From: Rémi Després <[email-masked]>
Date: Fri, 13 Apr 2012 17:53:22 +0200

> 1.  BCP OK as Fred suggested?  Or informational?

(1) This draft is IMHO quite useful.
Reason is that it is  AFAIK the only one so far to deal with:
v4-oly-APP / v6-only network / Stateful translator / v4-only Internet / v4 server

(2) Keeping it Informational (and without RFC2119 vocabulary) is IMHO much better.
Reasons are: 
a) Some requirements that amount to new specifications would not be acceptable in a BCP. (The need to exclude some prefix on the LAN side, and the need for a DHCPv6 option to provide a 464XLAT prefix, are AFAIK new specifications)
b) No information needs to be lost just because the RFC is Informational
c) Quick publication is less controversial (no need to clarify the relationship with the BIH of RFC6535)
d) Convergence of this work and that of Softwire, at least on address formats, might permit to complete and improve the design (see, for example, (3) below)

(3)  
If CLAT addresses would have the format proposed for 4rd-u in Softwire:
- each CLAT would need nothing more than is delegated /64 or shorter 
- v4-originated addresses would be deterministically distinguishable from native IPv6 addresses, both in CLAT themselves and in middle boxes
NB: this isn't to say that Softwire will necessarily publish the 4rd-u specification (the subject is still open). But it is to suggest that future coordination might be fruitful.

Regards,
RD

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