Subject: [v6ops] 464XLAT removing IPv6 LAN scope

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Sep 2012 12:36:54 -0700

Folks,

I hope we can all see the scope issue related /64 sharing across
interfaces, it is simply not germane to the function of 464XLAT and it
should be removed.

A much more workable solution, from IETF perspective, is to simply say
that 464XLAT supports the DHCP-PD scenario for a dedicated translation
prefix (no challenges that i know of), and in the case of no DHCP-PD
available the CLAT does normal CLAT function for IPv4 with NAT44 as
described in section 8.3.2

Meaning, there is an IPv6-only WAN and an IPv4 capable LAN, no
bridging or sharing of IPv6 across the CLAT is specified.

I would like to move forward with 464XLAT by simply stating that
DHCP-PD is the best choice for acquiring a dedicated /64 to be used
with stateless translation.

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2

For section 8.3.2 we can retain how IPv4 is treated with NAT44, but
simply remove how IPv6 is treated.

<removed text>

If the CLAT cannot perform ND Proxy [RFC4389] due to the restriction
   of the implementation, the CLAT may use a dedicated IANA assigned
   EUI-64 ID for creating a translated IPv6 address to be used in
   stateless translation [RFC6145].  This will allow the CLAT to avoid
   possible IPv6 address duplication issues between an IPv6 address for
   stateless translation [RFC6145] in the CLAT and an IPv6 address
   assigned to native IPv6 nodes behind the CLAT.  This document
   describes an example for this case in Example 2. of the Appendix A.

   The CLAT MAY discover the Pref64::/n of the PLAT via some method such
   as TR-069, DNS APL RR [RFC3123] or
   [I-D.ietf-behave-nat64-discovery-heuristic].

</removed text>

We can also remove the IANA section and remove reference to ND proxy.
If implementations choose to extend a /64 from WAN to LAN in cases
where DHCP-PD is not available, they may, but it is out of scope for
*THIS* I-D.  Hopefully some of the discussion here can feed further
work in this area that appears to be needed.

I believe this brings us back to pure 464XLAT which is an architecture
for double translation, not /64 cross-interface extensions and not a
CPE router specification.

Any technical issues with this approach?

CB

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Sep 2012 08:44:42 +0200

> work in this area that appears to be needed.

Not sure to understand what you mean by "extend a /64 from WAN to LAN in cases where DHCP-PD is not available".
(If a site only has a /64, there can be a LAN, but no prefix can be further delegated on this LAN, independently of code being available to support DHCP-PD.)

> CPE router specification.

In my recollection, NAT44s were introduced in the draft for LAN-supporting /64 sites.
Since then, we found that, with reserved IID ranges for CLATs, NAT44s are no longer needed for such sites.  

Then, could you clarify your intention:
Is it to exclude /64-sites from the 464XLAT scope? 
- If YES, 464XLAT would IMHO miss an important part of its natural target.
- If NO, are you intending to keep NAT44s in the draft?
 . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely stateless. This is contrary to the announced objective, and can't be justified, IMHO, as it an be avoided just with three CLAT IID subranges. (This reservation is to be made in a range already available for such reservations, and is to be registered by IANA as usual if needed for an IETF BCP).

> Any technical issues with this approach?

See above.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 11 Sep 2012 14:30:42 -0700

Rémi,

> - If NO, are you intending to keep NAT44s in the draft?

Yes, we can define NAT44 on the LAN but we cannot define how to share
a /64 from WAN to LAN.  Thus, the draft can only cleanly state how to
make a NAT44 LAN work with an IPv6-only WAN when DHCPv6 PD is not
available.

It's the state we find ourselves in.

>  . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely stateless. This is contrary to the announced objective, and can't be justified, IMHO, as it an be avoided just with three CLAT…

It is stateless at the CLAT in the case of DHCPv6 PD where a dedicated
/64 translation prefix exists. DHCP-PD is a SHOULD.

In the unfortunate case, but common in 3GPP today, where DHCPv6 PD
does not exist, the CLAT can do stateful NAT44 from the LAN so that
all IPv4 client packets are translated to 1 IPv4 address, and that 1
IPv4 address is then translated to 1 IPv6 address which is owned and
defended with DAD by the CLAT.

Thus, in a 3GPP network, IPv4 tethering can be supported across an
IPv6-only network using 464XLAT double translation and NAT44.  IPv6
tethering may also be supported by some method, but it will not
mentioned in the draft since the WG cannot come to an agreed approach
and it may be outside the scope of 464XLAT.

Rémi -- your solution is elegant and good.  But, you must agree that,
for reasons i don't understand, it is unpopular in the eyes of the WG.
 As one of the 464XLAT authors, i agreed to add it in previous version
of the I-D, but to move forward we must now remove it, and refocus the
scope of 464XLAT on 464 translation and not on managing LAN addresses.

 I would very much like to see your idea of reserved IID specified for
general application here in v6ops or 6MAN.

CB

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Sep 2012 10:02:10 +0200

Cameron,

Thanks for the clarification.
Unless I misunderstand, your currently favored plan is that, concerning tethering in /64 sites, the draft:
- supports it ONLY for IPv4
- imposes NAT44s to do it (stateful CLAT nodes)

Yet, with three currently unused IID ranges reserved for CLATs, the draft could, for /64 sites:
- Avoid imposing NAT44s (=> completely stateless CLAT nodes)
- Apply to sites that already do IPv6 tethering (independently of how they do it).

I don't share the view that a rough consensus with this solution would be impossible:
(a) The solution is AFAIK well understood by those who took the time to see how it works.
(b) Relevance of the solution has recently been supported by several contributors (including yourself here below in your last comment, and by the fact that, although you personally believe it is "unpopular in the WG", you qualify it with "for reasons i don't understand".)  
(c) A number of objections have indeed been expressed, but all have been proven to be unjustified: problems with cascaded CLATs (not applicable to /64 sites), problems with dual homing (precisely eliminated with reserved IID ranges), uncertainty of IANA acceptance (answered by Ron in Vancouver). 
(d) Incorporating it is particularly easy (see a proposal in www.ietf.org/mail-archive/web/v6ops/current/msg14077.html), bringing a simplification (no need for NAT44 sections), and an important scope extension (applicability to /64 sites that have their way to do IPv6 tethering). 

Conclusions:
- I still hope the WG won't refuse progress for reasons that at least neither you nor me can understand
- If the rough consensus reached would nevertheless be to refuse this progress, it will be without me.

Best regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 12 Sep 2012 05:58:34 -0700

On Sep 12, 2012 1:02 AM, "Rémi Després" <[email-masked]> wrote:
> (b) Relevance of the solution has recently been supported by several
contributors (including yourself here below in your last comment, and by
the fact that, although you personally believe it is "unpopular in the WG",
you qualify it with "for reasons i don't understand".)
> (c) A number of objections have indeed been expressed, but all have been
proven to be unjustified: problems with cascaded CLATs (not applicable to
/64 sites), problems with dual homing (precisely eliminated with reserved
IID ranges), uncertainty of IANA acceptance (answered by Ron in Vancouver).
> (d) Incorporating it is particularly easy (see a proposal in
www.ietf.org/mail-archive/web/v6ops/current/msg14077.html), bringing a
simplification (no need for NAT44 sections), and an important scope
extension (applicability to /64 sites that have their way to do IPv6
tethering).
> - If the rough consensus reached would nevertheless be to refuse this
progress, it will be without me.

All that said, is the wg ok with accepting with Remi's solution?

Silence means no support.

CB

> >> Not sure to understand what you mean by "extend a /64 from WAN to LAN
in cases where DHCP-PD is not available".
> >> (If a site only has a /64, there can be a LAN, but no prefix can be
further delegated on this LAN, independently of code being available to
support DHCP-PD.)
> >> . If YES, the 464XLAT BCP includes CLAT nodes that aren't completely
stateless. This is contrary to the announced objective, and can't be
justified, IMHO, as it an be avoided just with three CLAT IID subranges.
(This reservation is to be made in a range already available for such
reservations, and is to be registered by IANA as usual if needed for an
IETF BCP).

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Sep 2012 22:54:10 +0900

> Silence means no support.
If we can make it work, I think it has advantages. But it requires that the
text be written and that we as a WG think the issues through, try to figure
out if there are any corner cases, etc.  DAD is simple and we know how it
works, but we haven't devoted much thought to Remi's solution because it
hasn't even been written in the draft yet.

Realistically, what that means is that the draft will be delayed.

What are the alternatives?

1. Stay silent on sharing one /64 and let implementations do their thing.
2. Decide that for now it's more practical to share a /64 with DAD.
3. Remi's "reserve 3 IID ranges" proposal.

Anything else?

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 12 Sep 2012 07:00:55 -0700

On Sep 12, 2012 6:54 AM, "Lorenzo Colitti" <[email-masked]> wrote:
> If we can make it work, I think it has advantages. But it requires that
the text be written and that we as a WG think the issues through, try to
figure out if there are any corner cases, etc.  DAD is simple and we know
how it works, but we haven't devoted much thought to Remi's solution
because it hasn't even been written in the draft yet.
> 3. Remi's "reserve 3 IID ranges" proposal.

Yes.  Don't delay or bend the scope of 464xlat with Remi's good idea.
Instead, offer Remi's method as a generic solution for /64 sharing with a
broader scope and applicability than 464xlat. I would be happy to support
or work on that worthy effort.

CB

I

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 12 Sep 2012 07:06:47 -0700

> 1. Stay silent on sharing one /64 and let implementations do their thing.

Yes, stay silent in 464xlat draft. A new dedicated draft would be strongly
supported by me.

Implementers will always do their thing. One good example is Dan's code
that was submitted to AOSP. It works perfectly for sharing the /64, breaks
nothing, and is super simple. That code benefits from 464xlat staying
silent.

CB

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Sep 2012 16:08:20 +0200

2012-09-12 15:54, Lorenzo Colitti:

> If we can make it work, I think it has advantages. But it requires that the text be written and that we as a WG think the issues through, try to figure out if there are any corner cases, etc.  DAD is simple and we know how it works, but we haven't devoted much thought to Remi's solution because it hasn't even been written in the draft yet.

Note that, as reminded to Cameron in the mast mail I sent, a text of what the draft could become remains available in www.ietf.org/mail-archive/web/v6ops/current/msg14077.html.

RD

---

From: GangChen <[email-masked]>
Date: Wed, 12 Sep 2012 22:32:34 +0800

> Silence means no support.
Just want to share what we are doing for 464xlat. We are quite
following the draft, including the idea of "reserved IID"

Best Regards

Gang

>> > On Sun, Sep 9, 2012 at 11:44 PM, Rémi Després
>> > <[email-masked]>
> wrote:
>> >>

---

From: Dan Drown <[email-masked]>
Date: Wed, 12 Sep 2012 09:53:53 -0500

> Silence means no support.

 From the android implementation standpoint:

1. IPv6 tethering - having a reserved IID or IID range means not  
having to worry about having to DAD/answer NDs for the CLAT address on  
the "tethered" (downstream) interface.

2. NAT44 + 464XLAT vs 464XLAT - having a reserved IID range would mean  
not needing NAT44 on top of 464xlat

These are both nice to have but are not required to get 464xlat  
working on android.

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Sep 2012 17:05:13 +0200

Le 2012-09-12 à 16:00, Cameron Byrne a écrit :

> Yes.  Don't delay or bend the scope of 464xlat with Remi's good idea. Instead, offer Remi's method as a generic solution for /64 sharing with a broader scope and applicability than 464xlat. I would be happy to support or work on that worthy effort.
> 
If this becomes the conclusion (and it seems now clear it will be), I will see it as a missed opportunity for timely progress, caused by disproportionate FUD, but that's all.

Progress on this subject remains indeed possible in a second step, but it will have to be in your hands: having started working on something else in the field of operating systems, I will terminate active work in IETF (passionate but uncompensated) as soon as reasonably feasible. 

Congratulation to you and co-authors for what you achieved.
Good luck, and best regards,

RD

---

From: Ray Hunter <[email-masked]>
Date: Wed, 12 Sep 2012 18:23:52 +0200

The idea certainly has merit, but I'm not yet fully convinced about 
combining this with the 464XLAT draft.

The draft started off reserving one single IANA IID for IPv4 to IPv6 
translation. Now the reservation has expanded to cover the RFC1918 space.

If the IPv4 range used on networks behind the CLAT is limited to RFC1918 
space, and it is indeed kept strictly local, why do we need to reserve 
the complete 3 RFC1918 ranges for use as IID's (to be used to create 
unique IPv6 addresses when the IPv6 prefix assigned to the CLAT)?

Why can't everyone just use the identical set of 192.168/16 IPv4 
prefixes behind their own CLAT?

On the other extreme: if 464XLAT were to allow inbound PLAT to CLAT IPv4 
- IPv4 sessions (and not just support a hub and spoke model for outbound 
only sessions via the PLAT) why not reserve the entire /32 IPv4 address 
space as IANA IID's for use in generating unique IPv6 addresses for IPv4 
nodes located behind a CLAT? An equivalent approach has certainly been 
applied successfully in other transition mechanisms.

IHMO I think a lack of a clear answer to these extreme cases 
demonstrates it's simply too early to reserve IANA IID space right now.

regards,
RayH

Rémi Després wrote:
>> On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> If we can make it work, I think it has advantages. But it requires 
>> that the text be written and that we as a WG think the issues 
>> through, try to figure out if there are any corner cases, etc.  DAD 
>> is simple and we know how it works, but we haven't devoted much 
>> thought to Remi's solution because it hasn't even been written in the 
>> draft yet.
>
> Note that, as reminded to Cameron in the mast mail I sent, a text of 
> what the draft could become remains available in 
> www.ietf.org/mail-archive/web/v6ops/current/msg14077.html 
> <http://www.ietf.org/mail-archive/web/v6ops/current/msg14077.html>.
>
> RD
>
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Sep 2012 19:00:02 +0200

2012-09-12 18:23, Ray Hunter :

> The idea certainly has merit, but I'm not yet fully convinced about combining this with the 464XLAT draft.
> 
> The draft started off reserving one single IANA IID for IPv4 to IPv6 translation. Now the reservation has expanded to cover the RFC1918 space.
> 
> If the IPv4 range used on networks behind the CLAT is limited to RFC1918 space, and it is indeed kept strictly local, why do we need to reserve the complete 3 RFC1918 ranges for use as IID's (to be used to create unique IPv6 addresses when the IPv6 prefix assigned to the CLAT)?
> 
> Why can't everyone just use the identical set of 192.168/16 IPv4 prefixes behind their own CLAT?

Simply to avoid imposing an unnecessary constraint.
If a wireline sites needs more that 2^16 addresses, 192.168/16 isn't enough;
OTOH, there are implementations based on 192.168/1. No need to impose a change.
> 
> On the other extreme: if 464XLAT were to allow inbound PLAT to CLAT IPv4 - IPv4 sessions (and not just support a hub and spoke model for outbound only sessions via the PLAT) why not reserve the entire /32 IPv4 address space as IANA IID's for use in generating unique IPv6 addresses for IPv4 nodes located behind a CLAT? An equivalent approach has certainly been applied successfully in other transition mechanisms.

Out of scope AFAIAC.

> IHMO I think a lack of a clear answer to these extreme cases demonstrates it's simply too early to reserve IANA IID space right now.

In my understanding, just reserving 0.4 % of an IID range, already available in IANA for such reservation, wouldn't have been premature at all since at least some people understand how it permits to eliminate NAT44s in /64 sites that do IPv6 tethering.
Yet, I have stopped personally to argue against the too many who aren't ready to share this understanding (ref www.ietf.org/mail-archive/web/v6ops/current/msg14273.html).

Best regards,
RD 

>>> On Wed, Sep 12, 2012 at 9:58 PM, Cameron Byrne <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> Note that, as reminded to Cameron in the mast mail I sent, a text of what the draft could become remains available in www.ietf.org/mail-archive/web/v6ops/current/msg14077.html <http://www.ietf.org/mail-archive/web/v6ops/current/msg14077.html>.
>> 
>> RD
>> 
>>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Sep 2012 18:38:44 +0000

Rémi:

I think that there are two consensuses that we have reached. One is that 464XLAT, although we still need a -08 to finalize it, enjoys a rough consensus; you are the primary person objecting to it. The other is that your proposal should be discussed on its merits. Would you be willing to describe your proposal in a draft that can be discussed separately from 464XLAT, and could perhaps update the specification if/when agreed to? I'll note that networks that are *not* using 464XLAT may also find it useful.

Fred

---

From: Rémi Després <[email-masked]>
Date: Wed, 12 Sep 2012 22:02:37 +0200

Hi, Fred, 

As my efforts to contribute to progress in v6ops have come to an end (ref. www.ietf.org/mail-archive/web/v6ops/current/msg14273.html), I no longer object to any version of the 464XLAT draft. 

You let me feel, sometimes, that you didn't liked much of my contributions. Yet I believe you after all attributed some value to some of them, enough to have no regret.

All my wishes for the future, and best regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Sep 2012 09:53:10 +0900

On Wed, Sep 12, 2012 at 11:53 PM, Dan Drown <[email-masked]> wrote:

> These are both nice to have but are not required to get 464xlat working on
> android.
>

Speaking as an implementer, do you think it would be better for
implementers to implement Remi's idea and put it in the draft before it
becomes final, or ship the draft now and possibly fix up the
implementations later?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Sep 2012 10:06:32 +0900

On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <[email-masked]> wrote:

> I think that there are two consensuses that we have reached. One is that
> 464XLAT, although we still need a -08 to finalize it, enjoys a rough
> consensus; you are the primary person objecting to it.

It definitely looks like we're approaching rough consensus, but it seems to
me that there are two contentious points which we are still split on:

1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, or
2^24+2^20+2^16)
2. Whether to mention BIH or not.

What would be your guidance to the authors on these points?

> The other is that your proposal should be discussed on its merits. Would
> you be willing to describe your proposal in a draft that can be discussed
> separately from 464XLAT, and could perhaps update the specification if/when
> agreed to? I'll note that networks that are *not* using 464XLAT may also
> find it useful.
>

Which parts are you suggesting breaking out? The "ask IANA to reserve IIDs
in order to avoid having to rely on DAD" part? What IID do you think the
phone should use when operating as a standalone CLAT? Even if we break out
Remi's proposal to another draft, it would still be good to ensure that the
IIDs used there don't conflict with the ones used by a standalone CLAT.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 12 Sep 2012 18:19:23 -0700

On 9/12/12 6:06 PM, Lorenzo Colitti wrote:
> On Thu, Sep 13, 2012 at 3:38 AM, Fred Baker (fred) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I think that there are two consensuses that we have reached. One
>     is that 464XLAT, although we still need a -08 to finalize it,
>     enjoys a rough consensus; you are the primary person objecting to it.
>
>
> 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32, 
> or 2^24+2^20+2^16)
with my wg chair hat off, I don't see this as desirable.
> 2. Whether to mention BIH or not.
again in the same role, I think specifying it should be outside the 
scope of the document. mentioning it is not the same as specifying it.

---

From: t.petch <[email-masked]>
Date: Thu, 13 Sep 2012 10:26:14 +0100

----- Original Message -----
From: "Lorenzo Colitti" <[email-masked]>
To: "Fred Baker (fred)" <[email-masked]>
Cc: "IPv6 Ops WG" <[email-masked]>
Sent: Thursday, September 13, 2012 2:06 AM
> 1. Whether to ask IANA to reserve IIDs, and if so, how many (1, 2^32,
or

Lorenzo,

I agree, that these two points seem to me to be unresolved.

When you ask what guidance a WG Chair should give to an author, I would
prefer that the WG Chair be asked what they perceive to be the consensus
on these specific points, which, as you say, remain contentious (IMO).

And if the WG Chair cannot perceive a consensus, then I would like them
to be asked to take such steps as they need to in order to be able to
perceive a consensus and then declare it.

As I said before, I think
- BIH should not get a mention
- reserved IIDs is superior to a stateful NAT44 approach (the clue is in
the word stateful).

Tom Petch

> IIDs used there don't conflict with the ones used by a standalone
CLAT.

------------------------------------------------------------------------
--------

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

---

From: GangChen <[email-masked]>
Date: Thu, 13 Sep 2012 19:49:39 +0800

> - BIH should not get a mention

As far as I can say after several months discussions,

1) "Mentioning it is not the same as specifying it"
2) IPv4-IPv6 communication was the case 464xlat originally targeted
since it was introduced in draft -00. And BIH was identified as the
standard track RFC afterwards
3) The previous consensus was achieved to mention it. The recent
discussions re-open it (I hope we could achieve new consensus here)
4) Many more people are aware of the combination since such statement
was carried through several versions
5) *Mentioned or not* maybe important to some people who already
followed the draft and made implementation in parallel. It maybe
"don't matter" to others
6) Technical concerns about the combination have been answered unless
there is new point

> - reserved IIDs is superior to a stateful NAT44 approach (the clue is in

Current implementation is using the single reserved IID, at least we
can try the three ranges

Best Regards

Gang

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 14 Sep 2012 12:25:10 +0200

Hi Cameron,

your proposal works for me.

Regards,
Woj.

---

From: t.petch <[email-masked]>
Date: Tue, 18 Sep 2012 10:21:04 +0100

----- Original Message -----
From: "Ray Hunter" <[email-masked]>
To: "Rémi Després" <[email-masked]>
Cc: "IPv6 Ops WG" <[email-masked]>
Sent: Wednesday, September 12, 2012 5:23 PM

The draft started off reserving one single IANA IID for IPv4 to IPv6
translation. Now the reservation has expanded to cover the RFC1918
space.

<tp>
Ray

I never saw a direct response to your questions.  I think that the
answer is clear but that it depends on the assumptions made.

You could reserve the entire /32 IPv4 space and then you could allow
anyone to attach anything downstream.

You could limit downstream IPv4 attachments to 192.168/16 but that may
prove unduly restrictive - it depends on what is out there - I know of
uses of 10/8 in other contexts and there could be some here.

Allowing all RFC1918 addresses looks like a good compromise, that an
awful lot of 'CPE' boxes use this range and so by allowing that range,
most uses are covered.  Probably not all, but probably enough for most
if not almost all cases.

This is, for me, a judgement call (based, in my case, on limited
data:-(.

Tom Petch

regards,
RayH