Re: [v6ops] A way forward for 464XLAT

[Cameron Byrne <[e-mail]>]

On Apr 3, 2012 12:32 AM, "Rémi Després" <[e-mail]> wrote:
>
> Hi, Cameron,
>
> Sorry for the late answer (was on second priority for a few days).
>
> Le 2012-03-27 à 12:38, Cameron Byrne a écrit :
>
> > hi,
> >
> > On Tue, Mar 27, 2012 at 1:17 AM, Rémi Després <[e-mail]>
wrote:
> >>
> >> Le 2012-03-27 à 04:34, Fred Baker a écrit :
> ...
> >>>
> >>> 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?
> >>
> >> 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."
>
> Thanks, good enough for me.
>
> >> 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.
>
> BIH "recommends" to avoid double translation.
> This AFAIK permits it if good reasons are found.
>

Yes, it is an all capital letter recommendation.  As you likely well know,
ipv6 transition is an ecosystem transition and recommendations like the one
in BIH become a lightening rod for confusion. We can leave it at that.

> > 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, ...)
>
> BIH does include RFC6145 translation.
>

If I read section 2.3 correctly of bih, it requires all sessions be created
by enr.

In the network implementation of bih, bih cannot support ipv4 communication
that does not start with DNS because DNS triggers the enr. So, bih on a
router cannot facilitate for a client of  the router a Skype call  since
Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered
session mappings with capturing DNS first.

> > where BIH is constrained to
> > a host only style implementation that relies on host level API
> > modification and interaction
>
> A host can also be also a router, in particular if it includes a NAT44.
> I see nothing that prevents using it in this case.
>

I don't believe bih had this use case in scope. The diagrams and text in
bih make reference to a host, not a host / router.

Trust me, if bih worked as you suggest, my life would be much easier. If
bih officially worked with nat64 and did not require the enr mapper so that
it supported ipv4 literals in network mode, that would be great. In fact, I
pushed for both when bih was a draft in behave.

> >>>   - 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?
> >>
> >> 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.
> >>
> >
> > I hope my previous emails have made the case for a stateful solution
> > clear and useful
>
> I thought we had both understood that there are needs for stateful AND
ALSO for stateless, in particular where mesh topologies are desirable. This
depends on provider cases.
> End of this issue for me.
>

We do agree.

> > 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.
>
> Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without
saying that it doesn't do work for what it has been designed for).
>

We agree on this too.

Cb
> Regards,
> RD
>
> >
> > CB
> >> regards,
> >> RD
> >>
> >>
> >>>
> >>> 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?
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
>