Subject: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

From: Rémi Després <[email-masked]>
Date: Sun, 19 Feb 2012 15:29:03 +0100

Russ, Jari, Ralph, Fred,

On February 15, tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00.html was re-posted as a v6ops WG document (tools.ietf.org/html/draft-ietf-v6ops-464xlat-00.html).
Interpreting past v6ops discussion as a consensus for this to happen is AFAIK quite excessive (see in particular www.ietf.org/mail-archive/web/v6ops/current/msg11979), and besides that is inappropriate in view of WG charters and other existing drafts. 

Reasons AGAINST making it a v6ops document include AFAIK:

(1) There is an active 464XLAT draft IN SOFTWIRE (tools.ietf.org/html/draft-mawatari-softwire-464xlat-02.html), very similar, and still being discussed in this WG.

(2) Although the draft was presented in v6 pops as a "trial deployment report" (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its only reference to a deployment is "Incidentally, Japan Internet Exchange(JPIX) is providing 464XLAT trial service since July 2010" (it doesn't say how IPv6 /96 prefixes were assigned to customers, whether tested UEs included routers or not, whether they included DNS proxies or not, etc. etc.). On the contrary, it essentially includes specification of a NEW SOLUTION (in particular a new IPv6 address format).

(3) The v6ops charter does say  "Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues", BUT it also says "This work should PRIMARILY be conducted by those areas and WGs which are responsible and best fit to analyze these problems." 

(4) Softwire's charter has "Developments for stateless legacy IPv4 carried over IPv6". 
464XLAT introduces in user devices a  new stateless behavior, but one that is based on private IPv4 addresses like DS-lite, and one that uses IPv4 packet formats like those of MA-T or 4rd-U (three Softwire designs). SOFTWIRE therefore continues to be the right WG to pursue this work.

To conclude, a rectification of the situation would be to:
- cancel the ietf-v6ops-464xlat draft
- continue to work on the Softwire 464XLAT, in relationship with other stateless user-device solutions (hopefully with an updated draft version reflecting recent additions made in the v6ops draft)
 
Besides, and authors are willing to, a real "trial deployment report", with more deployment information, would be very welcome as an individually submitted draft.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 19 Feb 2012 07:58:40 -0800

Remi,

I am sorry there has been confusion.  Allow me to attempt to clarify

> Interpreting past v6ops discussion as a consensus for this to happen is AFAIK quite excessive (see in particular www.ietf.org/mail-archive/web/v6ops/current/msg11979), and besides that is inappropr…

The 464XLAT draft was posted as WG draft on Feb 15 at the direction of
the v6ops co-chairs

Please note the draft was first brought to v6ops for review on Jan 16,
link below

http://www.ietf.org/mail-archive/web/v6ops/current/msg11830.html

> (1) There is an active 464XLAT draft IN SOFTWIRE (tools.ietf.org/html/draft-mawatari-softwire-464xlat-02.html), very similar, and still being discussed in this WG.

I believe there is an active discussion in v6ops, not in Softwires.

On v6ops 464XLAT appears in email titles 55 times from today back till
December 1

There have been ZERO emails with 464XLAT in the title during the same
period softwires

In consultation with the co-chairs, we have moved the 464XLAT from
softwires to v6ops.  If you think the discussion is still going on in
softwires despite 3 months of silence where 464XLAT was in the title,
then i can send an email to softwiress making it clear that 464XLAT
has moved due to lack of interest and no charter scope within
Softwires to support further discussion.

> (2) Although the draft was presented in v6 pops as a "trial deployment report" (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its only reference to a deployment is "Incidentally, Japa…

You seem to have some technical questions about address assignment
that are all clear in the draft, and if not clear in the draft then
clear in the code.  I won't address them hear since they have already
been discussed in the draft and v6ops archive.  Feel free to start
another thread on specific technical clarifications after reviewing
the draft and discussion archive.

Allow me to clarify again the evolution of some of this.

I sent this email as a report on my trial of the 464XLAT draft.

http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html

The *draft* is not a trial report, the draft describes an architecture
that has been deployed in the USA and Japan.  That much is clear in
the first few lines of the draft.

The *email*  describes a trial that i have done where 464XLAT resolves
the 15% persistent brokenness for Android phones in an IPv6-only
NAT64/DNS64 network due to IPv4 referrals and so on.

I understand that became unclear as the v6ops discussion evolved.
Specifically, Fred forwarded the trial report email and asked for WG
consideration of the draft.  But, you will please understand that my
representation was that the *email* was a trial report of the *draft*
that describes an architecture.

> (3) The v6ops charter does say  "Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues",…

Agreed, that is the v6ops charter.  464XLAT does not define any new
standards.  It is an informational document that simply describes how
to use RFC6145 and RFC6146 to achieve the desired result of making
IPv6-only network acceptable for subscribers today.  The email i sent
regarding deployment report confirms the goals of the 464XLAT draft
can and are achieved.  We have running code, it is open source, and
all code has been contributed upstream pending acceptance.  This is
all live and working today because no new technologies are used.  It
is simply reusing existing capabilities.

> 464XLAT introduces in user devices a  new stateless behavior, but one that is based on private IPv4 addresses like DS-lite, and one that uses IPv4 packet formats like those of MA-T or 4rd-U (three…

This is NOT a stateless solution, it uses stateful RFC6146 AND
stateless RFC6145.  Please read the draft.    RFC6145 is not MAP or
4RD.

> - continue to work on the Softwire 464XLAT, in relationship with other stateless user-device solutions (hopefully with an updated draft version reflecting recent additions made in the v6ops draft)

I hope my clarification has made it clear that nothing needs to be
retracted and that Softwires is not the right place since no new
technology is being created and that 464XLAT is indeed both stateless
on the CPE/UE and stateful in the network, therefore Softwires is not
the right place. 464XLAT is an operator focused solution created and
deployed already by operators using existing IETF standards.

> Besides, and authors are willing to, a real "trial deployment report", with more deployment information, would be very welcome as an individually submitted draft.

My hope is that the trial deployment email was clear enough and yet
another ID would not be helpful.  The email on the trial deployment
report of 464XLAT referenced nearly 200 tested applications and all
the code and functions are open source, so anyone can repeat and
validate them.  For folks with a T-Mobile USA SIM and a Nexus S phone,
the steps are as simple as flash the provided images or compile from
source yourself.

Please accept that this draft is running code, open sourced,
validated in deployment, and solves a VERY REAL problem for network
operators that do not have IPv4 addresses and MUST continue to grow
their networks.  RIR exhaustion is real in Asia today and will be real
in North America this year.  The trial deployment has made clear, i
hope, that 464XLAT enables a mobile wireless provider to deploy
Android phones as IPv6-only and have service parity with existing
IPv4-only phones.

>From my perspective, this is a substantial achievement that the IETF
should support and expedite instead of slow.

I once again call on folks to read the draft and contribute to make it better

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00

If you can, also please review and trial the code yourself

http://dan.drown.org/android/clat/

CB

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

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 19 Feb 2012 08:37:47 -0800

So, when I read  464xlat what I see is a stack of existing RFCs used in
a specific fashion which the draft describes. I don't see any new
standards work.

There is comentary on the v6ops list from the map-t about deriving the
prefix of the core nat-64 translator in a consistent fashion across
draft, there is perhaps work to be done there though it is likely that
behave is the place for that, e.g.
(http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-05)

On 2/19/12 06:29 , Rémi Després wrote:

<snip>

> (4) Softwire's charter has "Developments for stateless legacy IPv4
> carried over IPv6". 464XLAT introduces in user devices a  new
> stateless behavior, but one that is based on private IPv4 addresses
> like DS-lite, and one that uses IPv4 packet formats like those of
> MA-T or 4rd-U (three Softwire designs). SOFTWIRE therefore continues
> to be the right WG to pursue this work.

softwires charter also says:

  IPv4/IPv6 translation mechanisms, new addressing schemes, and block
  address assignments are out of scope

which ought to rule out pretty much anything that has employs an rfc
6146 translator.

> To conclude, a rectification of the situation would be to: - cancel
> the ietf-v6ops-464xlat draft - continue to work on the Softwire
> 464XLAT, in relationship with other stateless user-device solutions
> (hopefully with an updated draft version reflecting recent additions
> made in the v6ops draft)

I'm not particularly wedded to the idea of it being in v6ops. I am
interested in seeing it get a fair hearing, the lack of novelty has some
relevance in an operational context.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Feb 2012 08:23:20 +1300

> a specific fashion which the draft describes. I don't see any new

fwiw I agree with that. I think v6ops is the appropriate venue
for descriptions of how to knit existing protocol specs together
in operational scenarios.

I do object slightly to the way draft-ietf-v6ops-464xlat uses
the word "architecture". It's an operational scenario, not an
architecture, IMHO.

   Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 19 Feb 2012 16:44:55 -0500

>in operational scenarios.

I would agree as well.  No new protocols.  We are using what's in the tool
kit to make things work.  Ops seems to be the right area for this type of
work

>the word "architecture". It's an operational scenario, not an

Are you concerned that the use of "architecture" may be interpreted as
protocol architecture vs. network architecture?  IMHO, I would suggest
what's in the document reflects a network/deployment architecture (my
opinion).

Perhaps authors can clarify what they meant.

Regards,

Victor K

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 20 Feb 2012 16:11:17 +0900

> the word "architecture". It's an operational scenario, not an

I can see a strong statement that double protocol translation is an architecture which is not recommended by the IETF.
(http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09)

I'd like to hear from chairs that does v6ops consent to be opposed to that statement.

cheers,
--satoru

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Feb 2012 10:52:28 +0100

cameron,

> The 464XLAT draft was posted as WG draft on Feb 15 at the direction of

That's why a lack of consensus is relevant.

> Please note the draft was first brought to v6ops for review on Jan 16,

Well known, but since then a number of comments suggested to send the document to some other WG.

> There have been ZERO emails with 464XLAT in the title during the same

Fair enough, but it was never closed, and I do believe it is useful to pursue it ("resume it" if you prefer).
There is room I think to include the concept (which BTW I find quite interesting) in the unified stateless solution under study in Softwire.
It seems to find a natural place there. 

> has moved due to lack of interest

True, little interest was expressed then, but this was when the work on MAP and 4rd-U was really beginning.
The work on these two has now progressed in Softwire, and considering functional requirements of 464XLAT in this context makes in my undesrtsnding a lot of sense.

> and no charter scope within

Debatable I suppose since 464XLAT was first submitted there.

> clear in the code.

Well, reading code is AFAIK a way to check that it complies to a spec, but not the right way to understand what a specification means. 
Specifications must be clear by themselves.

In any case, my question isn't about understanding the specification (clear enough IMHO for this level of discussion). It reflects interest for a more complete draft describing the trial configuration, with its configuration parameters. (The specification describes a number of options: with or without DNS64; possibility that an "access networks that does not allow for a dedicated translation prefix"; CLATs that may get /64s via DHCPv6 or by other means; inclusion fragment headers possibly systematic but optional; possibility for some CLATs to get longer than /64 IPv6 prefixes).

I just say that a real "trial deployment report" would be nice to have, but of course no obligation.

>  I won't address them hear since they have already

> consideration of the draft.

I agree that it is how confusion started. 

>  But, you will please understand that my

I do understand this, yes.

> IPv6-only network acceptable for subscribers today.  

The draft does include SHOULDs and MAYs that belong to standardization vocabulary, e.g.:
"In cases where the access network does not allow for a dedicated translation prefix, the CLAT SHOULD take ownership of the lowest /96 from an attached interface's /64 to source and receive translation traffic. Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP so that no other nodes on the /64 may use the lowest /96." 

> The email i sent
> can and are achieved.  

"IPv4 access service to mobile AND WIRELINE IPv6-only edge networks"? 
(From the abstract, upper cases added.)

> We have running code, it is open source, and

Close to that, but not "simply" (see above).

> stateless RFC6145.  

AFAIK, it adds rigorously nothing to NAT64 (RFC6146).
OTOH, it introduces a new CPE behavior that uses RFC6145, but adds few design choices to it, like MAP-T.
> Please read the draft.

Your suggesting that I didn't read the draft could advantageously have been avoided (IMHO).
 
>    RFC6145 is not MAP or

Why you say this is unclear. AFAIK nobody ever suggested that.
 
> deployed already by operators using existing IETF standards.

The claim that nothing new is specified is the main point that is challenged (see above)
> the steps are as simple as flash the provided images or compile from

The draft is about mobile AND "wireline" (understood to include DSL).

> Android phones as IPv6-only and have service parity with existing

This isn't sufficient to say that the specification is complete for all its use cases.
Besides, I would say that these phones are in some sense dual-stack:
- they are in all cases IPv4 aware, at least for IPv4-only applications
- if acting as routers, they "SHOULD" include IPv4-aware DNS proxies.

> should support and expedite instead of slow.

The idea is quite interesting, and quickly dealing with it in relationship with current work on MAP-T and 4rd-U makes a lot of sense (IMHO).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Feb 2012 11:27:11 +0100

Hi Joel,

Thanks for your comments.
More below.

> a specific fashion which the draft describes. I don't see any new

As answered to Cameron, the fact is that there are some new specification pieces, with SHOULDs and MAYs, e.g.:
"In cases where the access network does not allow for a dedicated translation prefix, the CLAT SHOULD take ownership of the lowest /96 from an attached interface's /64 to source and receive translation traffic. Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP so that no other nodes on the /64 may use the lowest /96." 

> which ought to rule out pretty much anything that has employs an rfc

Well, there is indeed ambiguity here because it also says:
"- develop a solution motivation document to be published as an RFC 
- develop a protocol specification response to the solution motivation document".
The MAP-T proposed solution is based on double RFC6145 translation, and 4rd-U uses some pieces that are specified only in RFC6145. 

> interested in seeing it get a fair hearing,

I share this interest in fair hearing.
Actually, that's why what it specifies should better be discussed where there is current work on stateless CPEs (hosts and/or routers) that do IPv4 via IPv6, i.e. in Softwire.
  
> the lack of novelty has some

I do share the view that using existing specifications to avoid reinventing the wheel is always good, but the fact is that there is some novelty in the 464XLAT specification.

Regards,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 20 Feb 2012 11:36:15 +0100

> the word "architecture". It's an operational scenario, not an

The operational experiment is something that deserves to be documented,
however it's as per my reading current quite a bit more given:
a) the presence of normative terms in the document
b) the emphasis on effectively specifying/casting the use of a very
specific subset of the stateless NAT64 spec eg just allowing the /96
address format to be used
c) the assumption that a stateless NAT64 client will always be used with a
stateful NAT64 core element

Based on my reading (and as exemplified in earlier email), should an
implementation follow this spec "as is", it would result in impaired
communication should a device supporting this spec "move" to a network
where b) and c) are different.

Cheers,
Wojciech.

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Feb 2012 12:05:30 +0100

Hi Brian,

> the word "architecture". It's an operational scenario, not an

The draft says "No new protocol required", but:

1. 
Section 7.5 says:
"In the best case, the CLAT will have a dedicated /64 via DHCPv6 or other means to source and receive IPv6 packets associated with the [RFC6145] stateless translation of IPv4 packets to the local clients."
How this is provided via DHCPv6 has AFAIK to be specified. 

Note that RFC5969 says "6rd specifies a protocol mechanism" although it is also using just a stack of previously available protocols, with new parameters obtained in DHCP.

2.
The same section says:

This is AFAIK a new specification, which requires specific code.
If not, I am interested in learning why.

3.
Section 7.6 says:
"In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, since IPv4 host does not set the DF bit."
AFAIK, this isn't in existing RFCs.

4.
Section 7.7 says:
"The CLAT SHOULD set itself as the DNS server via DHCP or other means and proxy DNS queries for IPv4 and IPv6 clients"
 I find the "other means" confusing here (a new protocol?). 
"The CLAT SHOULD allow for a client to query any DNS server of its choice and bypass the proxy."
 What the CLAT has to do for this isn't specified. (Also whether this DNS has to synthesize A records or not isn't specified.)     

To me this shows that, Devil being in details, this draft isn't just an operational scenario with existing RFC specifications.

Yet, as I said, there is in this draft a very valuable idea, worth treating rigorously.

Kind regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Feb 2012 07:32:04 -0800

> In any case, my question isn't about understanding the specification (clear enough IMHO for this level of discussion). It reflects interest for a more complete draft describing the trial configurat…

Glad to clarify this here.  My trial required no change to the
IPv6-only DNS64/NAT64 network beta service that i have offered to by
customers for close to 2 years now.  Adding 464XLAT was purely a CPE
function layered onto that existing network "as is".

1. Yes, we use DNS64

2. A dedicated translation prefix was not used.  Since my 3GPP Release
7 network does not support DHCP at all, the address is pushed to the
UE as part of PDP setup in the PCO IE.  This is how all IPv4 and IPv6
addresses are assigned to UEs in my network.

3.  The UE, which is also the CLAT, received a single /64 of IPv6 from
the network and no IPv4.  This is the only address scheme that was
used or can be used in my network

4.  There was no change to the RFC 6146/6145 behavior, fragment
headers were included.

5.  Pref64/n was discovered using draft-ietf-behave-nat64-discovery-heuristic

> I just say that a real "trial deployment report" would be nice to have, but of course no obligation.

I am attempting to operate as transparently as possible.  Please feel
free to query me further.

> "In cases where the access network does not allow for a dedicated translation prefix, the CLAT SHOULD take ownership of the lowest /96 from an attached interface's /64 to source and receive transla…

Correct.  The authors, including myself, are not as experience as you,
but i believe informational I-D may use this language.

Just looking, RFC6092 is informational and uses this language. Also,
we are open to changing the document type to BCP or Standard Track if
that is a better fit.  It has been recommended on list that this draft
go standards track.  So, i believe there is an open discussion here.
We can adjust as the WG sees fit.  Right now, i feel most comfortable
with informational.  I don't think experimental is helpful to network
operators that trying to solve a near term problem with "no new
technology".

> OTOH, it introduces a new CPE behavior that uses RFC6145, but adds few design choices to it, like MAP-T.

CPE is not an IETF standard.  So, changing its behavior to include
RFC6145 should not be controversial.

> Your suggesting that I didn't read the draft could advantageously have been avoided (IMHO).

Agreed.

> Why you say this is unclear. AFAIK nobody ever suggested that.

I keep getting the feeling like 464XLAT should be abandoned and the
use cases should be folded into MAP-T by the MAP-T author or 4RD-U
from the 4RD-U authors, both on and off list.  It seems the softwire
folks see 464XLAT as a competing technology. IMHO, MAP-T and 4RD-U do
not solve *my* problems.  We took time to document how 464XLAT is
unique in the draft.

I have brought to softwires the concern that stateless core NAT64 is
not acceptable given the address efficiency issues (please don't blast
me about how my issues are non-issues).  On the softwire list, i
brought this up and was told a /14 of IPv4 was probably needed to meet
a mid to large size wireless operator.  Unfortunately, these address
are not available in APNIC today and will not be available in ARIN or
RIPE in the very near future.... considering the timeline scope the
IETF operates at.  That said, the stateless solutions have an audience
with network operators that already have large allocations and wish to
be more efficient.  That's great, live and let live.

Also, the MAP family is quite complicated for me and lack of trial
deployment at scale is a concern since the IPv4 exhaustion issue is
pressing.

I hope you see that 464XLAT is an operational solution without any
novel technology.

> The claim that nothing new is specified is the main point that is challenged (see above)

I am still unclear on your overall concerns with 464XLAT.  Are these
your concerns?

1.  We add RFC6145 functions to a "CPE"

2.  We use SHOULD and MAY in an informational document?

> The draft is about mobile AND "wireline" (understood to include DSL).

Yes, i was commenting on my validation work in mobile.  It works in
wireline as well.

CB

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Feb 2012 07:45:23 -0800

> How this is provided via DHCPv6 has AFAIK to be specified.

If i may clarify,  DHCPv6 PD may provide the CPE with many /64.  The
CPE may choose any /64 that it is delegated for this purpose.  Nothing
new here. No special DHCP parameters.

> If not, I am interested in learning why.

I can tell you have seen this behavior before on a NAT-PT platform.
But, also nothing new IMHO.  The /96 is logically owned by the CPE as
a virtual address.  Thus, the CPE does NDP to avoid collisions.

> AFAIK, this isn't in existing RFCs.

Fragment header treatment is discussed here
http://tools.ietf.org/html/rfc6145#section-4

Does this answer your question?

>  I find the "other means" confusing here (a new protocol?).

We are trying to keep the architecture open for new standards track
work that may come some day.

>  What the CLAT has to do for this isn't specified. (Also whether this DNS has to synthesize A records or not isn't specified.)

We don't mention synthesized because it is not required.

The CLAT just has to do the defined CLAT functions including RFC6145

CB

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 20 Feb 2012 17:45:25 +0100

On 20 February 2012 16:45, Cameron Byrne <[email-masked]> wrote:

> > "In the best case, the CLAT will have a dedicated /64 via DHCPv6 or
> other means to source and receive IPv6 packets associated with the
> [RFC6145] stateless translation of IPv4 packets to the local clients."
> > Note that RFC5969 says "6rd specifies a protocol mechanism" although it
> is also using just a stack of previously available protocols, with new
> parameters obtained in DHCP.
> >
> > 2.
> > The same section says:
> > "In cases where the access network does not allow for a dedicated
> translation prefix, the CLAT SHOULD take ownership of the lowest /96 from
> an attached interface's /64 to source and receive translation traffic.
> Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP
> so that no other nodes on the /64 may use the lowest /96."
> >

As far as I can tell, there is no specification except the xlat464 draft
which (attempts to) define that a device with /64, or a PD, prefix should
derive a /96 from it and use the lower 32 bits for stateless mapping an(y)
received arbitrary source IPv4 addresses.
Yes there is clear use of existing stateless NAT64 here, applied in a very
specific way; the proof point being that any regular NAT64 capable device
that one would put on a network would, afaik, not accomplish all of the
above "auto magically" when connecting to the network.

-Woj.

>
> > 3.
> > Section 7.6 says:
> > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6
> Fragment Header, since IPv4 host does not set the DF bit."
> > "The CLAT SHOULD set itself as the DNS server via DHCP or other means
> and proxy DNS queries for IPv4 and IPv6 clients"
> >  What the CLAT has to do for this isn't specified. (Also whether this
> DNS has to synthesize A records or not isn't specified.)
> >
>
> > To me this shows that, Devil being in details, this draft isn't just an
> operational scenario with existing RFC specifications.
> >

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Feb 2012 18:23:19 +0100

Cameron,

Thanks for the additional information below.
More comments in line.

> On Mon, Feb 20, 2012 at 1:52 AM, Rémi Després <[email-masked]> wrote:
...
> function layered onto that existing network "as is".

OK. 
Could you clarify then what justifies that "It does not require DNS64".

> UE as part of PDP setup in the PCO IE.

Why, then, say "In the best case, the CLAT will have a dedicated /64"  

>  This is how all IPv4 and IPv6

Is this with a standard format (if yes, a reference would make it clear).

> the network

OK.

> and no IPv4.

(Already understood, otherwise nothing new would be needed)

>  This is the only address scheme that was

Then why to add a section which describes two variants.
Besides, I didn't understand this sentence "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 host does not set the DF bit*" (asterisks added). 
> 5.  Pref64/n was discovered using draft-ietf-behave-nat64-discovery-heuristic

OK.

> I am attempting to operate as transparently as possible.  

> Please feel

There is some of this of this above, thanks.

...
> Correct.  The authors, including myself, are not as experience as you,

I am not as much experienced in IETF procedures as you seem to believe.
Like yourself, I try to understand and apply BCPs.

> Just looking, RFC6092 is informational and uses this language.

Personally, I find it confusing in RFC6092, but this is another subject.

> Also,

My point is that it includes some behavior specification (464XLAT compliance is more than just compliance with RFCs it refers to).

...

> from the 4RD-U authors, both on and off list.

I don't know about off-list, but to say differently what think:
- abandoning the new idea expressed in the 464XLAT would be a very bad idea
- OTOH, dealing with it in the context of 4rd-U seems to me a good idea (unify stateless UE behaviors so that they can work consistently both in networks using stateful NAT64s and those using using with stateless ISP nodes)
- working together for this to happen in Softwire would be welcome on my side.

BTW, if you can take the time to read the 4rd-U draft, your questions and comments will be most welcome. 

>  It seems the softwire
> folks see 464XLAT as a competing technology.

I am an active Softwire guy, and don't see it that way.

> IMHO, MAP-T and 4RD-U do
> not solve *my* problems.

4rd-U isn't frozen yet.
I see solving your problem as an objective.

>  We took time to document how 464XLAT is
> unique in the draft.
> 
> me about how my issues are non-issues).

I never did, I hope, but I think I rather asked about real order of magnitudes of your problem.
Didn't get it yet.
Ideally that would include the number of simultaneous devices to be supported, and the size of the IPv4 space available, with lengths of IPv4 prefixes that compose it.
In any case, your requirement is yours,  and some other operators do have different requirements (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html).
That's why some coordination makes sense.
 
>  On the softwire list, i

I share this view on current MAP documents.

OTOH, I do think that making UEs that would support a 4rd-U, completed with permitted RFC1918 addresses in customer sites, would largely increase their applicability with a limited enough added complexity.

> I hope you see that 464XLAT is an operational solution without any

In my understanding, 464XLAT does introduce a quite useful technology that is almost completely based on existing pieces, like 6rd,  but this doesn't exclude these two from being NEW technologies. 

Regards,
RD

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 20 Feb 2012 09:42:52 -0800

> I never did, I hope, but I think I rather asked about real order of magnitudes of your problem.

Running a network with 30 million users and a /15 ip addresses is the
right order of magnitude to describe tmob. There are networks that are
larger but with proportionally fewer and smaller networks with a lot less.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Feb 2012 10:44:46 -0800

inline

> Could you clarify then what justifies that "It does not require DNS64".

464XLAT works fine without DNS64.

Meaning, the CLAT may do stateless RFC 6145 NAT46 to the IPv6-only
access network destine for RFC 6146 NAT64 towards the Internet

This is a complete solution for any IPv4-only hosts behind the CLAT.

For me, DNS64 is advantageous to use for the following reasons in *my* network

1.  DNS64 is already deployed in my network as part of the NAT64/DNS64
service i offer today

2.  DNS64 allows for the discovery of the Pref64 using
draft-ietf-behave-nat64-discovery-heuristic

3.  DNS64 allows for single translation in cases where the host and
application are capable of doing IPv6 but the server does not have a
AAAA record.  This is a very common case for my scenario.

Regarding discovery of the Pref64, the draft discusses that Pref64 may
be discovered through others means.  DHCP options in the future,
manual configuration, proprietary methods ... are all possible in the
future... Today i have draft-ietf-behave-nat64-discovery-heuristic
working but i do not want to constrain implementations to just those
that use DNS64.

> Why, then, say "In the best case, the CLAT will have a dedicated /64"

It just seems cleaner to me to have a dedicated /64 if it is
available.  Operationally, aside from the NDP claiming the /96, there
is no difference to have dedicated or not dedicated.

> Is this with a standard format (if yes, a reference would make it clear).

I was mistaken before, here is the reference for SLAAC being used for
address configurations.

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

> Besides, I didn't understand this sentence "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 host does not set the DF bit*" (asterisks added).

I think it may be wise to remove that language.  Let me check with my
co-authors.

> I never did, I hope, but I think I rather asked about real order of magnitudes of your problem.

Publicly available information is that T-Mobile USA has 30+ Million
subscribers and about 100,000 IPv4 addresses, total.  Not just for
subscribers, 100k IP addresses to run the whole business (data
centers, web sites, DNS servers, ...).

About 1/3 of those subscribers are actively attached to the data
network and consuming an IPv4 address, data network attachment is
growing

You can assume we are ~100% utilized on our IPv4 addresses, and that
nearly all subscribers reside behind existing 19 /25 public IPv4
pools.

My own Android phone has ~20 active TCP sessions at steady-state (push
updates from email, twitter, facebook, ...).  When i do tethering, it
goes up substantially.

As you can see, things are pretty tight.  They are going to get more tight.

We chose stateful NAT64 as a path forward since it was a simple
feature add that leverages the existing NAT44 hardware and /25 ipv4
NAT blocks.  This means that deploying NAT64 required no new IPv4
public addresses.  Going to 4RD-U and MAP-T would require a
substantial re-work of the network to provide a suitable pool of IPv4
addresses for the stateless translation.

We want 464XLAT since it enables us to make IPv6-only a feasible
service option to our subscribers in the near term, the only missing
piece from generally available code (shipping products) is the CPE /
UE to do the CLAT functions of RFC6145 and Pref64 discovery.  The
functions have been submitted to the Android Open Source Project.

That said, please don't try to re-engineer this network scenario on
the list.  This is a real scenario, lets not make it a diversion.

I tried to have this generic scenario discussion on softwires here
http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Feb 2012 09:34:39 +1300

On 2012-02-20 20:11, Satoru Matsushima wrote:
...
> I'd like to hear from chairs that does v6ops consent to be opposed to that statement.

Well, that's for the WG as a whole to say, not the chairs.

I hate translation, and I've hated it since RFC 1671. Therefore,
I hate double translation more. However, we are going to get
double translation anyway - via CPE NAT and CGN, or via 464XLAT.
It is a consequence of running out of IPv4 before the universal
deployment of IPv6.

I don't see one being more evil than the other, so it makes sense
to document the mechanisms.

   Brian

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 21 Feb 2012 12:05:31 +0900

> Well, that's for the WG as a whole to say, not the chairs.

It can be done by wg last call that is a chair's role.

> to document the mechanisms.

The mechanisms are well known already, I'm interested in that the document elaborate how the past IETF(IESG) statement doesn't make sense which statement should be disappeared consequently.

cheers,
--satoru

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 20 Feb 2012 20:47:24 -0800

On Feb 20, 2012 7:05 PM, "Satoru Matsushima" <[email-masked]>
wrote:
> >> I can see a strong statement that double protocol translation is an
architecture which is not recommended by the IETF.
> The mechanisms are well known already, I'm interested in that the
document elaborate how the past IETF(IESG) statement doesn't make sense
which statement should be disappeared consequently.

That decision might be best fit for draft-weil

http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15

That draft is nat444 space allocation, does not require any ipv6 strategy,
and it is in last call.  In the IESG notes I read, double translation was
not the core issue the IESG was concerned with. MAP-T also fits the
double/triple translation profile.
1.  464XLAT is not the first nor the last to use double translation. That
said, double translation is only a corner case in 464XLAT when DNS64 is
used.  See section 7.3 of 464XLAT draft for traffic treatment scenarios.

2.  464XLAT explicitly evolves to remove double and single translation
where possible, more v6 capable software and content as time goes on.

3.  464XLAT enables IPv6-only deployment in cases that would otherwise be
NAT444, including squat space usage.

4.  On my network, after World IPv6 Launch, over 50% of the traffic
delivered to the average user on a mobile will be IPv6 end-to-end, if the
subscriber is IPv6 enabled.  They cannot be IPv6 enabled until 464XLAT is
implemented (see motivations for draft-464XLAT on reasons why dual-stack
and tunnels do not work for my scenarios)

CB

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 21 Feb 2012 16:12:31 +0900

First, I'd like to see that the authors request wg last call.

On 2012/02/21, at 13:47, Cameron Byrne wrote:

> [--snip--]
> That draft is nat444 space allocation, does not require any ipv6 strategy, and it is in last call.  In the IESG notes I read, double translation was not the core issue the IESG was concerned with. MAP-T also fits the double/triple translation profile.

I won't argue that which statement is best fit to which document.

> 1.  464XLAT is not the first nor the last to use double translation. That said, double translation is only a corner case in 464XLAT when DNS64 is used.  See section 7.3 of 464XLAT draft for traffic treatment scenarios.

One clarification. Is it true that double translation is a corner case in 464XLAT _when DNS64 is used_?

> 2.  464XLAT explicitly evolves to remove double and single translation where possible, more v6 capable software and content as time goes on.

BIH and MAT-T are same on that aspect.

> 
> 3.  464XLAT enables IPv6-only deployment in cases that would otherwise be NAT444, including squat space usage.  
> 4.  On my network, after World IPv6 Launch, over 50% of the traffic delivered to the average user on a mobile will be IPv6 end-to-end, if the subscriber is IPv6 enabled.  They cannot be IPv6 enabled until 464XLAT is implemented (see motivations for draft-464XLAT on reasons why dual-stack and tunnels do not work for my scenarios) 
> 
> 

Great. Good lack to see that at June 6.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 21 Feb 2012 16:42:36 +0900

> One clarification. Is it true that double translation is a corner case in 464XLAT _when DNS64 is used_?

Now I got what you mean 'a corner case'. Thanks.
--satoru

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Feb 2012 16:21:14 +0100

Cameron,

Thanks for these answers,
More questions and comments below.

 Le 2012-02-20 à 19:44, Cameron Byrne a écrit :
...
>>>   My trial required no change to the

Well,  the discovery heuristic that you used implies DNS64 (ref. the quote just below from draft-ietf-behave-nat64-discovery-heuristic).
Without DNS64, some more assumptions seem to be needed for IPv4 hosts to get A records, but I couldn't figure out which ones on my own. 
  "When sending AAAA query for the known name a host MUST set "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not perform IPv6 address synthesis hence does not reveal the IPv6 prefix(es) used for protocol translation."

> access network destine for RFC 6146 NAT64 towards the Internet

Aren't NAT64s always coupled with DNS64s, as seems to be implied by all scenarios of RFC6144?
 
> is no difference to have dedicated or not dedicated.

Understood, but:
- Claiming a /96 on a link seems new to me (is there an existing reference?)
- Avoiding the need to do it is AFAIK an improvement, proposed in 4rd-U thanks to the V-octet discriminator of 4rd addresses.
- If DNS64s are parametrized to synthesize addresses that have the V octet, finding IPv4 addresses in IPv6 addresses can become deterministic instead of heuristic. 

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

Thanks.

> I think it may be wise to remove that language.  Let me check with my

OK

>> BTW, if you can take the time to read the 4rd-U draft, your questions and comments will be most welcome.

Renewed statement.

> nearly all subscribers reside behind existing 19 /25 public IPv4

I suppose that these 19 prefixes were derived by you from a smaller number of shorter allocated prefixes, right?
That is these shorter prefixes that are relevant.  

> updates from email, twitter, facebook, ...).

A key complementary information is the proportion of these that will work in IPv6 where IPv6 is available.
Any idea of this proportion?

>  When i do tethering, it

BTW, did the trial include tethering?
In the model, is tethering to be supported with a NAT44 in the UE? 
If not, how?  

> 
> As you can see, things are pretty tight.

Agreed, but not impossible, see near the end of this email.

> They are going to get more tight.

Not so sure as far as IPv4 is concerned: as IPv6 gets really deployed, less and less sessions will consume IPv4 ports.

> public addresses.  

> Going to 4RD-U and MAP-T would require a

How substantial this rework is does depend on each operator's starting point, but AFAIK it is quite feasible (see the example near the end of this email)

> service option to our subscribers in the near term,

> the only missing
> UE to do the CLAT functions of RFC6145 and Pref64 discovery.

Right, there is _little_ to add to what exists,  but still _something_.
That much has to be rigorously specified (the Devil is in details).

>  The

Well done.

> the list.

I just try to understand what you mean, and which part has been validated.
I am also interested in simplifications that result from unifying good designs.

Suggesting I try to re-engineer is something that could have been avoided (IMHO).

>  This is a real scenario,

No doubt about this.

> lets not make it a diversion.

There is no intent to divert, only to work for progress.
 
> http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html

Indeed and you did receive several answers, including one from me (http://www.ietf.org/mail-archive/web/softwires/current/msg03406.html).

Note that this contradicts your previous assertion that there was no discussion about 464XLAT in Softwire in the last 3 months (9 e-mails in early February do contain "464XLAT")

>> That's why some coordination makes sense.

Your reasons are obviously legitimate in _your_ environment. 

Yet, it is IMHO interesting to note that, with figures you gave above (30+ million subscribers, 1/3 active, 100k IPv4 addresses), static address sharing a la 4rd-U might realistically be introduced:
- Move a fraction of the IPv4 addresses from dynamic to static sharing  say 32K addresses, i.e. 33%. (NAT 64 usage will naturally be reduced as UEs start using their statically assigned shared addresses instead of NAT64s).
- Choose a sharing ratio of 512, in order to support 32K*5124= 16,777,216 UEs (more than 1/3 * 30+ millions)
- Thus, without losing the benefit of NAT64 for UEs that don't support 4rd-U, each UE gets a shared public IPv4 address, with 120 reserved ports for sessions that can't be IPv6.

Please consider that there is no aggressiveness in pointing this out, just the wish to see realities as they are.
My wish is cooperation, not useless competition without understanding valid points others have made.

>>> a mid to large size wireless operator.

What is important is the total size of the available IPv4 space, not the length of the shortest prefix. 

Regards,
RD

>>> Unfortunately, these address

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Feb 2012 09:21:30 -0800

> More questions and comments below.

Remi, thanks again for you rigorous review.

>> 464XLAT works fine without DNS64.

I don't really understand the below clearly, I will try to answer the best i can

> Without DNS64, some more assumptions seem to be needed for IPv4 hosts to get A records, but I couldn't figure out which ones on my own.

Without DNS64, the draft-ietf-behave-nat64-discovery-heuristic is not
used to discover Pref64. Some other means must be used.
draft-ietf-behave-nat64-discovery-heuristic is a known working case
today, others may emerge.

> - Claiming a /96 on a link seems new to me (is there an existing reference?)

It does not need to claim the /96 as a whole.  The CLAT will do NDP
with the idea that each /128 in the /96 is owned by the CLAT as a
virtual address.

I have seen this behavior in NAT-PT deployments, but i do not see it
specifically declared in the NAT-PT RFC.

> That is these shorter prefixes that are relevant.

IPv4 allocations are frequently fragmented as they are assigned piece
meal. So yes, there are shorter prefix, but it is a fragmented set of
prefixes.

> Any idea of this proportion?

No, but i am optimistic.

> BTW, did the trial include tethering?

No, that is a feature that is still lacking in the code.  I hope to
have it covered soon.

>From the draft:

   CLAT:   CLAT is Customer side translator(XLAT) that complies with
           [RFC6145].  It algorithmically translates 1:1 private IPv4
           packets to global IPv6 packets, and vice versa.  The CLAT
           function is applicable to a router or an end-node such as a
           mobile phone.  CLAT SHOULD perform router function to
           facilitate packets forwarding through the stateless
           translation even if it is an end-node.  In addition to
           stateless translation, the CLAT as a common home router or 3G
           router is expected to perform gateway functions such as DHCP
           server and DNS proxy for local clients

I hope this makes it clear why NAT44 on the tethered phone / mobile
router is not required.  The PC that is tethered passes IPv4 packets
that are immediately translated on the CLAT using 6145 to the
IPv6-only access network.  This is the same in the case for wireline
CPE.

> Suggesting I try to re-engineer is something that could have been avoided (IMHO).

Agreed, since you are going to change the inputs substantially
regardless of my request.

> Note that this contradicts your previous assertion that there was no discussion about 464XLAT in Softwire in the last 3 months (9 e-mails in early February do contain "464XLAT")

No contradiction, i said 464XLAT appeared in 0 email titles.

> Please consider that there is no aggressiveness in pointing this out, just the wish to see realities as they are.

I said that 100% of the IPv4 addresses are utilized in place, and you
are suggesting above that 32% of my total IPv4 address holdings can be
made available for a stateless BR.  That is not realistic.

Please note this section of the draft well
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4

CB

---

From: Rémi Després <[email-masked]>
Date: Tue, 21 Feb 2012 19:42:03 +0100

...
> today, others may emerge.

"May emerge" is good enough an answer.
Thanks.

...
>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by all scenarios of RFC6144?

An answer to this?

...
> with the idea that each /128 in the /96 is owned by the CLAT as a

Was understood.

> specifically declared in the NAT-PT RFC.

Right, it seems to be new material as far as IETF is concerned.

...
> meal.

Indeed.
This is why 4rd-U can, with several mapping rules, assign shared addresses that start with prefixes of a fragmented IPv4 space. 

> So yes, there are shorter prefix, but it is a fragmented set of
> prefixes.

OK.

>> Any idea of this proportion?

So am I.
The number of ports needed for IPv4 should very quickly decrease wherever IPv6 is enabled.

OK.

>           server and DNS proxy for local clients

OK.
(Apologies for having asked a superfluous question.) 

> IPv6-only access network.  This is the same in the case for wireline

Understood.
There may be some issues about hosts that query the NAT, e.g. with multicast for UPnP.
This is similar to DS-lite, but RFC6333 only says "Discussion of multicast is out of scope for this document." 

>> Suggesting I try to re-engineer is something that could have been avoided (IMHO)

> regardless of my request.

Sorry, I don't understand what you are talking about.
It sounds like a disapproval of something I do here, but I can't follow what that is.

...
> No contradiction, i said 464XLAT appeared in 0 email titles.

OK.
(Apologies for having missed you were talking only about titles.)

...
> made available for a stateless BR.  That is not realistic.

Well, I suppose it is possible in NAT64s to change the set of IPv4 addresses they use.
Reducing these sets when many customers will cease using NAT64s (because they now use statically shared IPv4 addresses instead), seems to me quite reasonable.

Note that for an operator that hasn't deployed NAT64s, and can go directly the stateless way, the problem is a lot simpler.
With the same numbers of customers and IPv4 addresses, each UE could easily be assigned twice as many ports per CE.

> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4

I think I understand your motivations, and hope you can understand those of draft-ietf-softwire-stateless-4v6-motivation.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 21 Feb 2012 11:34:46 -0800

Remi

>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by all scenarios of RFC6144?

Sorry i missed this earlier.

In the case for RFC6144 to replace NAT-PT functionality, yes a DNS64
and NAT64 must be coupled to replace NAT-PT functions.

But, RFC6146 and RFC6147 stand on their own.  There is no explicit
coupling required or shared state between NAT64 and DNS64 for them to
perform their atomic functions.  Meaning, any conforming packet
(Pref64+32bit IPv4 destination address) may be received by an RFC6146
stateful NAT64 and be translated.  A properly configured CLAT that
knows the Pref64 may received IPv4 packets and translate them via
RFC6145 to a PLAT without any queries or interactions with the DNS64.

> Right, it seems to be new material as far as IETF is concerned.

NDP for a host address should not be new material.  As i mentioned
before, we can treat each address in the /96 as a host address on the
CLAT, and the interactions are normal for NDP host addresses.

Alternatively, we may view the CLAT in terms of proxy NDP
http://tools.ietf.org/html/rfc4861#section-7.2.8

The CLAT is willing to accept packet destine to the /96 on behalf of
the IPv4 internet, and the NDP actions are defined as existing Proxy
NDP.

Thoughts on one verse the other?

> I think I understand your motivations, and hope you can understand those of draft-ietf-softwire-stateless-4v6-motivation.

Yes, and thanks again for your careful review and attention to the 464XLAT draft

CB

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Feb 2012 11:40:19 +0100

Cameron,
It seems we are close to common understanding.
More below. 

Le 2012-02-21 à 20:34, Cameron Byrne a écrit :
...
...
> RFC6145 to a PLAT without any queries or interactions with the DNS64.

I don't think a NAT64 that wouldn't work for IPv6-only hosts is a scenario that needs to be mentioned, especially since it contradicts an existing RFC.
IMHO, stating that, with a CE architecture like that of the 464XLAT draft, a stateless CE can work with a stateful NAT64 is enough.
Adding that it can work without DNS64 is AFAIK at best unnecessary, at worst confusing.
That could advantageously be deleted (IMHO). 
 
...
> NDP for a host address should not be new material.  

Nothing is new in your proposal for hosts, right, but NDP operation IS modified in CE routers. 

> As i mentioned

Understood. 
The fact that this is new in the router CE is not a problem AFAIAC, but provided new pieces of design are clearly identified.

> http://tools.ietf.org/html/rfc4861#section-7.2.8

Doesn't this require support of RFC3810 (Multicast Listener Discovery Version 2 (MLDv2) for IPv6)?
That could be part of the specification, but would AFAIK would be a constraint. 

> Thoughts on one verse the other?

My thought is that BOTH can be AVOIDED.
It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that differs from all valid native IPv6 prefixes.
This is easy to have, and is part of the 4rd-U proposal.
The architecture you propose can easily benefit from it, simply by adding its scenario as a particular one of the 4rd-U general scheme. 

> Yes, and thanks again for your careful review and attention to the 464XLAT draft

I confirm that IMHO your draft brings quite useful new material.

If you can take time to look at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03, my hope is that you will understand that coordination between its contents and that of your draft should be useful.

Regards,
RD

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 22 Feb 2012 08:10:59 -0600

> > Alternatively, we may view the CLAT in terms of proxy NDP

I think that pNDP is unnecessary. NDP is good enough here. 

Also, when we move to using DHCP-PD, then NDP on WAN int will not be necessary either.

> Nothing is new in your proposal for hosts, right, but NDP operation IS modified

Remi, what is modified in your view?

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rémi Després
> Sent: Wednesday, February 22, 2012 5:40 AM
> To: Cameron Byrne
> Cc: v6ops WG; Russell Housley
> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe an
> ietf-v6ops I.D.
> 
> Cameron,
> I don't think a NAT64 that wouldn't work for IPv6-only hosts is a scenario that
> needs to be mentioned, especially since it contradicts an existing RFC.
> IMHO, stating that, with a CE architecture like that of the 464XLAT draft, a
> stateless CE can work with a stateful NAT64 is enough.
> The fact that this is new in the router CE is not a problem AFAIAC, but provided
> new pieces of design are clearly identified.
> 
> The architecture you propose can easily benefit from it, simply by adding its
> scenario as a particular one of the 4rd-U general scheme.
> 
> >> I think I understand your motivations, and hope you can understand those of
> draft-ietf-softwire-stateless-4v6-motivation.
> >>
> >
> If you can take time to look at http://tools.ietf.org/html/draft-despres-softwire-
> 4rd-u-03, my hope is that you will understand that coordination between its
> contents and that of your draft should be useful.
> 
> Regards,
> RD
> 
> 
> 
> 
> >
> > CB
> >
> >> Regards,
> >> RD
> >>
> >>
> >>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 22 Feb 2012 16:03:38 +0100

> Remi, what is modified in your view?

Compliance with the 464XLAT draft requires specific code that none of the referenced RFCs specifies.
This code is to prevent other LAN hosts not only to avoid the router's address, as usual, BUT all addresses starting with the chosen /95. 

Cheers,
RD

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 22 Feb 2012 12:12:26 -0600

Hi Remi,

> This code is to prevent other LAN hosts not only to avoid the router's
> address, as usual, BUT all addresses starting with the chosen /95.

Well, the code is nothing special, since it is part of typical NDP/DAD to prohibit a LAN host from using router's addresses (say).

However, the valid point you have is that if the LAN host duplicated the same address as that of the router (/96 based addresses, say), then the LAN host would be deprived of the address (and possibly global IPv6 connectivity).

Of course, if there is no host in the LAN, then this problem is moot. Perhaps, 464XLAT deployment assumes the lack of LAN hosts.

Cheers,
Rajiv

> From: Rémi Després [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2012 10:04 AM
> To: Rajiv Asati (rajiva)
> Cc: Cameron Byrne; v6ops WG; Russell Housley
> Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not tobe
> an ietf-v6ops I.D.
> 
> 
> >> Nothing is new in your proposal for hosts, right, but NDP operation IS
> modified
> >> in CE routers.
> >
> This code is to prevent other LAN hosts not only to avoid the router's
> address, as usual, BUT all addresses starting with the chosen /95.
> 
> Cheers,
> RD
> 
> 
> >
> > Cheers,
> > Rajiv
> >
> >
> >>>>>> Aren't NAT64s always coupled with DNS64s, as seems to be implied
> by all
> >> scenarios of RFC6144?
> >>>>
> >>>> An answer to this?
> >>>>
> >>>
> >> Adding that it can work without DNS64 is AFAIK at best unnecessary, at
> worst
> >> confusing.
> >> Nothing is new in your proposal for hosts, right, but NDP operation IS
> modified
> >> in CE routers.
> >>
> >>> As i mentioned
> >> Doesn't this require support of RFC3810 (Multicast Listener Discovery
> Version 2
> >> (MLDv2) for IPv6)?
> >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that differs
> from all
> >> valid native IPv6 prefixes.
> >>> Yes, and thanks again for your careful review and attention to the
> 464XLAT
> >> draft
> >>

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 22 Feb 2012 10:23:27 -0800

> Well, the code is nothing special, since it is part of typical NDP/DAD to prohibit a LAN host from using router's addresses (say).

Yes.  This is clear, and this behavior has been demonstrated in
commercial NAT-PT systems.

> However, the valid point you have is that if the LAN host duplicated the same address as that of the router (/96 based addresses, say), then the LAN host would be deprived of the address (and possi…

It will not be deprived, it will be made aware via NDP that that
address is in use therefore it must select another address.

As described in the draft, the CLAT may also serve as a DHCPv6 server
and therefore will avoid the situation entirely for DHCPv6 clients
since the CLAT is capable and aware that the /96 is already in use.

> Of course, if there is no host in the LAN, then this problem is moot. Perhaps, 464XLAT deployment assumes the lack of LAN hosts.

No, we definitely make it clear in the draft that LAN hosts are in scope.

CB

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 22 Feb 2012 10:59:09 -0800

> It seems we are close to common understanding.

Yes, I do believe that is the case.

Once again, thanks for your time in reviewing this work.

 If i may summarize your remaining technical concerns:

1.  The CLAT will claim the /96 on the LAN via NDP or by marking the
/96 as used in the local DHCPv6 server of the CLAT.   In the case of
non-DHCPv6 LAN clients, I believe this is normal NDP action for a
router to claim it's addresses to avoid address conflict. I believe
you said you are OK with this action as long as the draft is clear on
it.

2. You believe the scenario for operation without the DNS64 is
confusing in its current form. We can add a section that explicitly
explains this scenario vs DNS64 scenario, is that ok?

3.  Cameron will do a detailed technical review of 4RD-U and submit
comments to Softwire.

More in line

> That could advantageously be deleted (IMHO).

We'd like to keep it, since DNS64 is not always available or fit for a
given network.  Others have submitted feedback on list that they
believe it is important for hosts to be able to use the DNS server of
their choice, not the provider DNS64.

We can add a section that makes the packet flow for operation without
a DNS64 clear, would that help?

> The fact that this is new in the router CE is not a problem AFAIAC, but provided new pieces of design are clearly identified.

To be clear, you are OK with the NDP action on the CE?  We can add
language to make it more clear in the draft.

> That could be part of the specification, but would AFAIK would be a constraint.

I am open to discussion on the right path forward for this.

> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix that differs from all valid native IPv6 prefixes.

Yes, in the draft, we state a dedicated /64 for the purpose of
translation is best.  But, we also recognize that is not always
available, such is the case for mobile networks.

> If you can take time to look at http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03, my hope is that you will understand that coordination between its contents and that of your draft should…

I will do this, but first my time is prioritized in resolving
technical issues of 464XLAT

CB

---

From: Rémi Després <[email-masked]>
Date: Thu, 23 Feb 2012 10:00:23 +0100

Cameron,

Le 2012-02-22 à 19:59, Cameron Byrne a écrit :

> /96 as used in the local DHCPv6 server of the CLAT.  

Even if it does the second, it must do the first because hosts MAY use SLAAC.
Right?

>  In the case of
> router to claim it's addresses to avoid address conflict.

The router claims its address, yes, but not 2^(128-96) addresses (more than 4 billions)

> I believe

I understand it can work, yes.

I also say that the need for it can easily be avoided.
For this, just make sure IPv6 addresses that represent IPv4 addresses are, in hosts that support IPv4 applications, distinguishable from native addresses.
The V octet of R24 in http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 does it.

> explains this scenario vs DNS64 scenario, is that ok?

If you still find it useful to say that there may be no DNS64, yes, an explanation would be welcome.
Yet, in view of RFC6144 in which all scenarios have DNS64 where there are NAT64s, I would personally suggest to avoid dealing with this independent problem in your draft (a minor point though).

> 3.  Cameron will do a detailed technical review of 4RD-U and submit

I do look forward to it. 

...
> their choice, not the provider DNS64.

AFAIK, having a DNS64 deployed doesn't force all hosts to use it.
A sentence reminding it would make no harm.

> a DNS64 clear, would that help?

Same answer as above.

> language to make it more clear in the draft.

Same answer as above.

> I am open to discussion on the right path forward for this.

As already suggested, the easiest path to get rid of this problem would be to permit hosts that support IPv4 applications to distinguish native IPv6 addresses from those that represent IPv4 addresses, even with a single assigned IPv6 prefix.
Your comments on this are welcome.

> available, such is the case for mobile networks.

As said, the V octet of 4rd-U brings the benefit of a dedicated /64 without needing to have one.

Regards,
RD

---

From: Washam Fan <[email-masked]>
Date: Thu, 23 Feb 2012 21:07:54 +0800

Hi Cameron,

Just one point. See below please.

> address is in use therefore it must select another address.

DAD failure would cause the address invalid,i.e., you can not use this
address for any purpose. at least, i observed this on Linux.

Thanks,
washam

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 23 Feb 2012 06:25:20 -0800

Thanks Remi. It sounds like all technical issues have been resolved. We
will update the draft for based on the groups feedback.  Thanks again.
> Even if it does the second, it must do the first because hosts MAY use
SLAAC.

Yes

> The router claims its address, yes, but not 2^(128-96) addresses (more
than 4 billions)

Yes

> I understand it can work, yes.

Great

> For this, just make sure IPv6 addresses that represent IPv4 addresses
are, in hosts that support IPv4 applications, distinguishable from native
addresses.
> The V octet of R24 in
http://tools.ietf.org/html/draft-despres-softwire-4rd-u-03 does it.

I will study this

> If you still find it useful to say that there may be no DNS64, yes, an
explanation would be welcome.

We will add more clarity

> Yet, in view of RFC6144 in which all scenarios have DNS64 where there are
NAT64s, I would personally suggest to avoid dealing with this independent
problem in your draft (a minor point though).

ack

> > 3.  Cameron will do a detailed technical review of 4RD-U and submit

Me too

> >> IMHO, stating that, with a CE architecture like that of the 464XLAT
draft, a stateless CE can work with a stateful NAT64 is enough.
> >> Adding that it can work without DNS64 is AFAIK at best unnecessary, at
worst confusing.
> >> Nothing is new in your proposal for hosts, right, but NDP operation IS
modified in CE routers.
> >> The fact that this is new in the router CE is not a problem AFAIAC,
but provided new pieces of design are clearly identified.
> >> Doesn't this require support of RFC3810 (Multicast Listener Discovery
Version 2 (MLDv2) for IPv6)?
> As already suggested, the easiest path to get rid of this problem would
be to permit hosts that support IPv4 applications to distinguish native
IPv6 addresses from those that represent IPv4 addresses, even with a single
assigned IPv6 prefix.
> >> It is sufficient for this to use, for IPv4 traffic, an IPv6 prefix
that differs from all valid native IPv6 prefixes.
> As said, the V octet of 4rd-U brings the benefit of a dedicated /64
without needing to have one.

This again for detailed review.

Cb