Re: [v6ops] A way forward for 464XLAT

[Cameron Byrne <[e-mail]>]

Fred,

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

On Mon, Mar 26, 2012 at 7:34 PM, Fred Baker <[e-mail]> 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
>
>        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?

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.

>    - How does it fit the the mdt-softwire-map specifications, which
>      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

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

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

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

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.

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

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