Subject: [v6ops] A way forward for 464XLAT

From: Fred Baker <[email-masked]>
Date: Tue, 27 Mar 2012 04:34:32 +0200

I won't say "chair hat off", but "chair hat fashionably tipped to one side." I'm trying to figure out the best way forward for the 464XLAT specification in view of comments by the authors of 

	http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u
	http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib
	http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib
	http://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation
	http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation
	http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port
	http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd
	http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast

and notably the comments in the working group meeting Monday morning. Why do I comment on the "chair hat"? Well, I'm not "giving instruction", as chair; I'm floating an idea. If the idea is acceptable, the idea may become instruction; if it needs to be modified, I want to have that conversation.

The objections raised in the working group come down to:
    - the authors of said other documents would like to have a conversation with the 464XLAT folks
    - What's this about a prefix::/96?
    - What's this about a proxy service?
    - What's this about normative language?
    - How does it fit the the mdt-softwire-map specifications, which
      appear to have a growing consensus behind them in softwire?

Before you continue reading this note, please stop and read these two sections:
    http://tools.ietf.org/html/rfc2026#section-4.2.2
    http://tools.ietf.org/html/rfc2026#section-5

From my perspective, and from reading those definitions, an Informational Document is a white paper, while a BCP is something that a significant and relevant part of the Internet COmmunity agrees to, and

...since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.

In other words, operational service models, while not strictly speaking "protocols", can be described in a BCP *standard* as "how to implement a certain service". This is in no sense "the best" or "only way to deploy RFCs 6145/6146", but it might be "the best way to deploy the CLAT service". v6ops is authorized, by charter, to write informational and BCP documents.

And since a BCP describes the set of things that one MUST or SHOULD do in deploying such a service, RFC 2119 language regarding that specific service may be acceptable in a BCP describing that service.

With that preparatory reasoning, it seems to me that we need to separate the contentious parts of the specification so that uncontentious parts can go forward, and other parts can be discussed - whether in this working group or another one.

Given the points of contention, it seems that the separation needs to be among three documents.

The first is a specification - a BCP - for the CLAT service. It refers to RFCs 6052/6144/6145/6146/6147, and describes how translation is used in this context using normative language. It does not refer to a prefix::/96; it refers to RFC 6052. My understanding is that several people have said that this specification is interesting and useful.

The second is a separate specification for the proxy service, which is contentious. Being separated, it can be discussed and beaten to death as needed. The first specification says that the CLAT service MAY implement this proxy service. I'm not sure whether that is BCP or Informational; we can discuss that in the context of the rest of the discussion of the proxy service.

The third is a report on the trial deployment of the CLAT service by the various companies in question. This is an informational document.

Am I making sense? Would this be an acceptable way forward?

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Mar 2012 21:25:06 -0700

Fred,

Speaking for myself, as i have not consulted with my co-authors prior
to writing this.

>    - What's this about a prefix::/96?

The /96 is defined here
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.1

We chose to use a /96 instead of all the possible variants within
RFC6052 since it is the common and logical way to deploy uniformly,
and this predictability allows
draft-ietf-behave-nat64-discovery-heuristic to execute quicker and the
devices within the 464XLAT architecture to operate more smoothly since
the prefix size is known ahead of time.

Constraining RFC6052 seems like a logical step that is prudent, why
have variables in places they are not needed??  To this list, there
has been no scenario presented where /96 is harmful in 464XLAT
scenarios, aside from Woj... i believe his concerns were that CLAT
with /96 will clash with his MAP-T CPE, which requires /128.  MAP-T is
not a dependency for 464XLAT.

If it is the WG consensus that the /96 section be removed, it shall be
removed.  If it is just Woj and he is only concerned about MAP-T, i
don't see that is WG consensus or in scope.  This much should be well
documented in the mailing list archives.

>    - What's this about a proxy service?

I assume you mean DNS proxy
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.4

It was discussed on this list a few times.  I believe the WG
understood the idea and some clarifying language was added to 01 rev.
But, the DNS proxy functions is yet another logical thing that an
operator would want.  It is not required, and if the WG requires it to
be removed, that section too can be deleted.  It is my understanding
that many CPE today set themselves as the DNS server and proxy DNS to
the ISP DNS server, that is all that is being done here.  The goal is
saving DNS queries from having to go across the stateful PLAT from
IPv4 clients by having the CPE proxy the IPv4 request as a native IPv6
query to the native IPv6 DNS server without crossing the PLAT.

>    - What's this about normative language?

RFC2119 language was removed in the 01 rev.  Woj, i believe, is still
thinking that the /96 constrains RFC6052, and that constitutes
normative language.  I disagree with his logic, but once again, the WG
has the choice to make a call here and that call will be reflected in
the draft.  My hope is that the decisions are driven based on operator
needs for operating a 464XLAT architecture, not on interoperability
with an alternate transition solutions.

>      appear to have a growing consensus behind them in softwire?

Yes, i follow softwires.

Anyhow, as stated here
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4

In summary, the 464XLAT architecture works today for service
   providers that require large-scale strategic IPv6 deployments to
   overcome the challenges of IPv4 address scarcity.  Unlike other
   transition architectures associated with tunneling or
   [I-D.mdt-softwire-mapping-address-and-port], 464XLAT properly assumes
   that IPv4 is scarce and IPv6 must work with today's existing systems
   as much as possible.  In the case of tunneling, the tunneling
   solutions like Dual-Stack Lite [RFC6333] are known to break existing
   network based deep packet inspection solutions like 3GPP standardized
   Policy and Charging Control (PCC). 464XLAT does not require much IPv4
   address space to enable the stateful translation [RFC6146] function
   in the PLAT while providing global IPv4 and IPv6 reachability to
   IPv6-only wireline and wireless subscribers.

It is also worth noting that 464XLAT allows for port-overloading,
meaning that 1 IPv4 address can support millions (n * 64,000 ports) of
translations sessions, which MAP cannot do.  This is a very important
point that should not be taken lightly.  New entrants may only get
/22s in APNIC today and in RIPE very soon, after that ... they can get
nothing unless you pay some private party $$$$ for something they
acquired for free.  It is not possible to, for example, launch a new
LTE service in large country using stateless translation... the
benefits of IPv4 address fixed sharing (MAP) vs statistical
multiplexing (NAPT) vs statistical multiplexing and overloading (NAPT
* N) should be clear w.r.t scaling.  It is a matter of being in
business or not being in business..... and if the LEC / PTT has all
the IPv4 address since creation... and you are a new entrant... well,
you are at a substantial disadvantage... unless you can get a small
chunk of IPv4 and overload such that each IPv4 address can support
millions of sessions.

And, 464XLAT does not rely on stateful DHCP.  This is important to me
since 3GPP does not support any stateful DHCP solutions.

"Stateful DHCPv6-based address configuration [RFC3315] is
   not supported by 3GPP specifications."

http://tools.ietf.org/html/rfc6459#section-5.2

So, MAP solutions do not fit 3GPP (GSM/UMTS/LTE) networks, AFAIK.

On the other hand, what we have specified in 464XLAT demonstrably
works in 3GPP networks.  It also demonstrably works in wireline
networks, and will be needed in any network where aggregate
subscribers sessions exceed IPv4 holdings available for CGN * 64,000

>    http://tools.ietf.org/html/rfc2026#section-5

ACK, what stands out most for me is that informational documents are "timely".

> The second is a separate specification for the proxy service, which is contentious. Being separated, it can be discussed and beaten to death as needed. The first specification says that the CLAT se…

Having a CPE optionally cache and proxy DNS requests should not be
contentious. The rather generic CPE i use at home gives me a DNS
server address  of 192.168.1.1 ... this is the same thing CLAT would
do.

> Am I making sense? Would this be an acceptable way forward?

I am sorry i am not in Paris, and perhaps if i was there in person i
could understand why some of these issues are contentious when they
have been discussed to an end on the mailer.

It was my understanding that the DNS proxy and /96 were addressed on
the mailing list, and that the concerns about /96 were limited to Woj.
 I don't recall any other voices on this topic.

Personally, i do not relish this sausage making that is standards
works.  I am eager to move forward with running my network.   That
said, i am open to any proposal that moves us forward quickly.
Informational documents are "timely" and i believe the document is in
good shape today and has rough consensus and running code and deployed
network.

If stripping /96 and DNS proxy moves us forward as BCP quick, while
informational means more sausage making, lets roll with BCP.  My
assumption was that BCP was going to be steeper climb, and thus
slower.

To that end, i look to the chairs and WG for guidance.

CB

---

From: Rémi Després <[email-masked]>
Date: Tue, 27 Mar 2012 10:17:21 +0200

> 	http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast

I haven't seen comments in v6ops of authors of all these documents.
OTOH, I read the 4X4XLAT spec, had a useful dialogue with Cameron Byrne about it on the ML, and wish to pursue cooperation with 464XLAT author.
Yet, this list gives me impression that this work isn't welcome in v6ops, without understanding why.

>   - What's this about a proxy service?

There was also a point about NAT44 in CLAT nodes or not (point discussed on the ML)

May I add that the relationship between 464XLAT and BIH (RFC6535) would also be worth clarifying. (I see high similarity: v4 only applications communicating in IPv6).

>     appear to have a growing consensus behind them in softwire?

The point made during the meeting was about the work in Softwire in general. replacing this point by a reference to the mdt draft is a biased interpretation.
In Softwire, a choice between MAP and Unified is scheduled for Friday morning. As chair of v6ops, it would be better to avoid making a Softwire choice before the scheduled debate has taken place (IMHO).
Thanks.

regards,
RD

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Mar 2012 10:34:08 +0000

On 27 Mar 2012, at 06:25, Cameron Byrne wrote:

> It is my understanding
> the ISP DNS server, that is all that is being done here.

They do, but the main rationale is to defeat the chicken-and-egg problem of not knowing which DNS servers to offer the client when you haven't yet learnt any from your upstream WAN link.

See RFC 5625.

Ray

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 27 Mar 2012 03:38:27 -0700

hi,

> There was also a point about NAT44 in CLAT nodes or not (point discussed on the ML)

The NAT44 text on the CLAT has been integrated here:

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

"Alternatively, the CLAT may do NAT44
   such that all private IPv4 sourced LAN packets appears from one
   private IPv4 address which is statelessly translated to one IPv6
   address that the CLAT will own as a host IPv6 address from an IPv6
   /64 interface."

> May I add that the relationship between 464XLAT and BIH (RFC6535) would also be worth clarifying. (I see high similarity: v4 only applications communicating in IPv6).

BIH explicitly does not allow double translation, it's scope is
explicitly limited to the case of using IPv4 applications to IPv6-only
servers.  I objected to this limitation in BEHAVE.  But, it is what it
is.

That said, 464XLAT authors have found rfc6145 to be the best fit for
IPv4->IPv6 translation, including support for the function in a more
generic node such as a router (home gateway CPE, mobile phone as a
host, mobile phone as a wifi router, ...) where BIH is constrained to
a host only style implementation that relies on host level API
modification and interaction

> In Softwire, a choice between MAP and Unified is scheduled for Friday morning. As chair of v6ops, it would be better to avoid making a Softwire choice before the scheduled debate has taken place (I…

I hope my previous emails have made the case for a stateful solution
clear and useful

As it stands, there is no workable stateful (more IPv4 address
efficient / intensive) IETF method of operating in an IPv6-only access
network.  NAT64/DNS64 is not workable, since 15% of applications on
mobile (something similar for desktop) fail to work without some way
to deal with IPv4 specific sockets and IPv4 literals.

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

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 27 Mar 2012 03:44:29 -0700

Hi,

> They do, but the main rationale is to defeat the chicken-and-egg problem of not knowing which DNS servers to offer the client when you haven't yet learnt any from your upstream WAN link.

ACK.

" The CLAT should allow for a client to query any DNS server
   of its choice and bypass the proxy."

Does the current text of the draft not properly address the desired behavior?

It is probably worth adding a reference to RFC5625

CB

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 28 Mar 2012 17:22:31 +0200

Hi Fred,

the proposed way forward makes sense to me. There appears to be a desire to
have an "implementers spec" for a NAT64 client-device, along with some
default settings, and assuming that this is based on existing NAT64
standards and not based on some "hard coded" values, it's fine to progress
as a separate draft.

Regards,
Woj.

On 27 March 2012 04:34, Fred Baker <[email-masked]> wrote:

> I won't say "chair hat off", but "chair hat fashionably tipped to one
> side." I'm trying to figure out the best way forward for the 464XLAT
> specification in view of comments by the authors of
>
> and notably the comments in the working group meeting Monday morning. Why
> do I comment on the "chair hat"? Well, I'm not "giving instruction", as
> chair; I'm floating an idea. If the idea is acceptable, the idea may become
> instruction; if it needs to be modified, I want to have that conversation.
>
> From my perspective, and from reading those definitions, an Informational
> Document is a white paper, while a BCP is something that a significant and
> relevant part of the Internet COmmunity agrees to, and
>
> In other words, operational service models, while not strictly speaking
> "protocols", can be described in a BCP *standard* as "how to implement a
> certain service". This is in no sense "the best" or "only way to deploy
> RFCs 6145/6146", but it might be "the best way to deploy the CLAT service".
> v6ops is authorized, by charter, to write informational and BCP documents.
>
> And since a BCP describes the set of things that one MUST or SHOULD do in
> deploying such a service, RFC 2119 language regarding that specific service
> may be acceptable in a BCP describing that service.
>
>
> With that preparatory reasoning, it seems to me that we need to separate
> the contentious parts of the specification so that uncontentious parts can
> go forward, and other parts can be discussed - whether in this working
> group or another one.
>
>
> The first is a specification - a BCP - for the CLAT service. It refers to
> RFCs 6052/6144/6145/6146/6147, and describes how translation is used in
> this context using normative language. It does not refer to a prefix::/96;
> it refers to RFC 6052. My understanding is that several people have said
> that this specification is interesting and useful.
>
> The second is a separate specification for the proxy service, which is
> contentious. Being separated, it can be discussed and beaten to death as
> needed. The first specification says that the CLAT service MAY implement
> this proxy service. I'm not sure whether that is BCP or Informational; we
> can discuss that in the context of the rest of the discussion of the proxy
> service.
>
> The third is a report on the trial deployment of the CLAT service by the
> various companies in question. This is an informational document.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Mar 2012 18:28:51 +0200

> that this specification is interesting and useful.

Sounds reasonable to me.

I take that it can't become a proposed standard because proposed standards
are, by definition, new specifications and thus can'e be addressed in v6ops?

---

From: Fred Baker <[email-masked]>
Date: Wed, 28 Mar 2012 18:56:32 +0200

On Mar 28, 2012, at 6:28 PM, Lorenzo Colitti wrote:

> I take that it can't become a proposed standard because proposed standards are, by definition, new specifications and thus can'e be addressed in v6ops?

In part. For another part, while it would make sense to move RFC 6145/6146/6147 through the PS/DS/FS/OS (Obsolete Standard) sequence, I'm not sure how you would carry out a plugfest for 464XLAT as a specification.