Subject: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 25 Aug 2012 15:54:23 +0000

I do have to start a new thread to focus this ND Proxy discussion with 464xlat.   Elide the use case of a single /64 from the document and then the following go away too.

1.      ND Proxy

2.      RFC 4389

3.      Single /64 allocated to the CLAT

During the IPv6 CPE router specification development, for a long time, some folks from the 3GPPP community asked us to add a use case for a single /64 and ND Proxy to rfc6204.  However, after more careful study, a consensus was reached to remove the single /64 use case from rfc6204 and rfc6204bis.   Additionally, I am told the IETF  endorses the  DHCPv6 PD model over a single /64.

A single /64 cannot be supported on a CPE/CLAT because then the CPE has to proxy the RA to hosts in the LAN or tethered segment.  There is no document on a Standards Track in the IETF that defines how to proxy an RA.  I am assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in the wireless service provider domain.   If the cellular network does not issue an RA to the CLAT/UE/CPE, how does the UE know it's ipv6 default router?   How is the /64 assigned to the CLAT?

Hemant

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 25 Aug 2012 09:48:10 -0700

On Sat, Aug 25, 2012 at 8:54 AM, Hemant Singh (shemant)
<[email-masked]> wrote:
> I do have to start a new thread to focus this ND Proxy discussion with
> 464xlat.   Elide the use case of a single /64 from the document and then the
> following go away too.
>
>
>
> 1.      ND Proxy
>
> 2.      RFC 4389
>

Single /64 is the reality of many of today's access networks, and
specifically important is all deployed 3GPP networks work this way for
IPv6.  Note, there are no known Release 10 networks deployed or any
known support of 3GPP DHCP-PD, AFAIK.  It is known that IPv4 resources
are exhausted in APNIC, and soon to be so in RIPE and then ARIN.  So,
there is no point in waiting for perfect. A single /64 is the only
reality we know in 3GPP, and is therefore the most concrete thing we
have for this BCP, which includes running code / running network.

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

5.3.  Prefix Delegation

   IPv6 prefix delegation is a part of Release-10 and is not covered by
   any earlier releases.  However, the /64 prefix allocated for each
   default bearer (and to the UE) may be shared to the local area
   network by the UE implementing Neighbor Discovery proxy (ND proxy)
   [RFC4389] functionality.

>
> During the IPv6 CPE router specification development, for a long time, some
> folks from the 3GPPP community asked us to add a use case for a single /64
> and ND Proxy to rfc6204.  However, after more careful study, a consensus was
> reached to remove the single /64 use case from rfc6204 and rfc6204bis.
> Additionally, I am told the IETF  endorses the  DHCPv6 PD model over a
> single /64.
>
>

I am also told the IETF endorses dual-stack

>
> A single /64 cannot be supported on a CPE/CLAT because then the CPE has to
> proxy the RA to hosts in the LAN or tethered segment.  There is no document
> on a Standards Track in the IETF that defines how to proxy an RA.  I am

Is a standard tack document required?  I assume the point you are
trying to make is that rfc4389 is experimental status.

> assuming the CLAT CPE sees an IPv6 ND RA from an upstream IPv6 router in the
> wireless service provider domain.   If the cellular network does not issue
> an RA to the CLAT/UE/CPE, how does the UE know it’s ipv6 default router?
> How is the /64 assigned to the CLAT?
>
>

If you are wondering how 3GPP side works, start here rfc6459

CB

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

---

From: Ray Hunter <[email-masked]>
Date: Sat, 25 Aug 2012 21:27:36 +0200

The single /64 deployment model conflicts with previous approved IETF 
BCP. I was also vocal in the discussion on 6204bis.

Specifically: According to BCP 157 RFC6177 "A key principle for address 
management is that end sites always be able to obtain a reasonable 
amount of address space for their actual and planned usage, and over 
time ranges specified in years rather than just months."

The single /64 deployment model may be reality of Release-9 3gpp, but 
should we be producing a new (xlat) BCP that potentially condones bad 
practice forever? Especially as future releases of 3gpp seem to be 
moving away from the single /64 deployment model.

I'm worried that we'll create issues for Homenet, because an IPv6 
wireless LTE mobile phone acting as a CPE router (with built in CLAT and 
special processing for single /64 working) is pretty likely to connect 
into a Homenet in parallel to a domestic wired CPE router (with built in 
CLAT).

Can you remove that worry?

Does the WG think Lorenzo's and Hemant's vision of a tethered mobile 
phone as "just another CPE router" the more correct model?

regards,

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 25 Aug 2012 19:54:31 +0000

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]] 
Sent: Saturday, August 25, 2012 12:48 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>I am also told the IETF endorses dual-stack

It's comparing apples to oranges.  Dual-stack works.  The DHCPv6 PD is recommended by the IETF (at least for the IPv6 CPE router document) over a single /64 because a single /64 has issues supporting tethered clients while the DHCPv6 PD does not.

>Is a standard tack document required?

No.

>I assume the point you are trying to make is that rfc4389 is experimental status.

Not quite.  rfc4389 is experimental because the protocol specified by the document has issues.  The issues were pointed out recently by me to v6ops.  See

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

If one deploys a single /64 to a UE and the UE has to support tethered clients, the UE will have to proxy the RA.  How is the proxy RA implemented?  Note also, that is why the IPv6 protocol WG in 6man is standardizing a DAD proxy (draft-ietf-6man-dad-proxy) on standards track but not any ND Proxy which still stays as experimental.  

Thanks for the rfc6459 reference. 

Hemant

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 25 Aug 2012 13:40:50 -0700

Hi Ray,

On Sat, Aug 25, 2012 at 12:27 PM, Ray Hunter <[email-masked]> wrote
> The single /64 deployment model conflicts with previous approved IETF BCP. I
> was also vocal in the discussion on 6204bis.
>
> management is that end sites always be able to obtain a reasonable amount of
> address space for their actual and planned usage, and over time ranges
> specified in years rather than just months."
>

Without ND proxy, the amount of address you have is exactly zero for a
tethered device in all of today's 3GPP networks.  So the question is
do we do allow tethering on IPv6 today or do we say "no, IPv6 is
future exercise for someone else".  Failing to engineer for it now
makes yet another chicken-and-egg issue.  No customers, no demand, no
spec, no gear, no code, ...

On my 3GPP Release 7 network, you may tether today with NDproxy and
have access to the WAN /64 on your LAN.

As soon as kit arrives that can do DHCP-PD, that will be the preferred
mechanism.

I believe that is clearly documented here:
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-07#section-8.3.2

IF DHCP-PD available, then use DHCP-PD to grab as much address space as needed

Else if NDproxy available, do that

Else if EUI-64 reserved address available, do that.

> The single /64 deployment model may be reality of Release-9 3gpp, but should
> we be producing a new (xlat) BCP that potentially condones bad practice
> forever? Especially as future releases of 3gpp seem to be moving away from
> the single /64 deployment model.
>e

It does not condone NDproxy forever, i believe the current text is
clear that DHCP-PD is the preferred path.  Given that that the
preferred path is only available in vaporware on 3GPP networks and
this is a BCP, we documented what we know to work in a 3GPP network
for real .. with real code .. .real customers .... real production
network.  While, at the same time, saying DHCP-PD is the best path
when available

> I'm worried that we'll create issues for Homenet, because an IPv6 wireless
> LTE mobile phone acting as a CPE router (with built in CLAT and special
> processing for single /64 working) is pretty likely to connect into a
> Homenet in parallel to a domestic wired CPE router (with built in CLAT).
>

Homenet has a lot of work to do on many fronts, and finding network
boundaries is one of their most active areas of research

> Can you remove that worry?

I hope i already have.

> Does the WG think Lorenzo's and Hemant's vision of a tethered mobile phone
> as "just another CPE router" the more correct model?

I have my reservations about the commercial reality of multi-homing
for residential use, but i think it is viable.

CB

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 25 Aug 2012 15:31:53 -0700 (PDT)

----- Original Message -----

> From: Ray Hunter <[email-masked]>
> To: Cameron Byrne <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Sunday, 26 August 2012 5:27 AM

<snip>

> phone as "just another CPE router" the more correct model?

I think it is. A "Smartphone" isn't really a "phone", it is a portable personal computer that can make phone calls. With multiple network interfaces (*G, Wifi, bluetooth) they can easily become multi-homed hosts or routers just with a bit of the right software.

When we re-redid the RADIUS authentication and accounting systems at Internode to support IPv6 we allowed for the DHCPv6-PD transaction to occur at any time after the session had started. This was to allow for a mobile device to change from having a host role at the start of the session to a router role later in the session (and allowed for it to change back). The use case was tethering. (And to make IPv4/IPv6 support more robust, during the development of this "occasional" DHCPv6-PD support, we also allowed for IPv4 and IPv6 to appear and disappear during the life of the PPP session, because PPP supports that too).

The GUA SLAAC on the link to the customer's device + DHCPv6-PD GUA prefix method of address assignment supports direct attachment of hosts (laptops, smartphones, desktops), routers (e.g. ADSL CPE) and hosts that might turn into routers and then turn back into hosts (smartphones).

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 25 Aug 2012 18:38:24 -0700 (PDT)

----- Original Message -----

> From: Cameron Byrne <[email-masked]>
<snip>

I think the problem is that if the following sort of thing happens and becomes popular, 

> As soon as kit arrives that can do DHCP-PD, that will be the preferred

Temporary work-arounds have a horrible habit of becoming permanent work-arounds, and their temporary disadvantages then become permanent ones. If DHCPv6-PD is the proper solution, then I don't think anything else should be acceptable. The requirement for DHCPv6-PD support will create the demand for DHCPv6-PD to then be widely implemented.

Regards,
Mark.

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 25 Aug 2012 18:49:57 -0700

> Temporary work-arounds have a horrible habit of becoming permanent work-arounds, and their temporary disadvantages then become permanent ones. If DHCPv6-PD is the proper solution, then I don't thin…

Market demand for IPv6?  I seen that movie.

In any event, the draft describes one thing.  What you have described
is FUD, and you suggest that because of FUD "we cannot have nice
things"

CB

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 26 Aug 2012 01:05:09 -0700 (PDT)

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>
> Cc: Ray Hunter <[email-masked]>; "[email-masked]" <[email-masked]>
> Sent: Sunday, 26 August 2012 11:49 AM
>>  Temporary work-arounds have a horrible habit of becoming permanent 
> work-arounds, and their temporary disadvantages then become permanent ones. If 
> DHCPv6-PD is the proper solution, then I don't think anything else should be 
> acceptable. The requirement for DHCPv6-PD support will create the demand for 
> DHCPv6-PD to then be widely implemented.
>> 
> 

Who said anything about market demand? The demand I'm talking about is compliance with standards.

> is FUD, and you suggest that because of FUD "we cannot have nice

So wanting the best and proper solution from the outset, rather than a work around that has known disadvantages is FUD? That doesn't make sense to me.

---

From: Ray Hunter <[email-masked]>
Date: Sun, 26 Aug 2012 13:39:11 +0200

Inline. Thanks!
> Cameron Byrne <mailto:[email-masked]>
> 25 August 2012 22:40
> Hi Ray,
>
> On Sat, Aug 25, 2012 at 12:27 PM, Ray Hunter<[email-masked]>  wrote
Understand that. No problem with a phone using xlat for it's own 
internal mono-stack apps. Or in a stand alone LAN where the phone is the 
only router.

I'm just trying to understand interoperability when there's more than 
one device present: either in parallel or cascaded.

When asked what happens when CLAT's are cascaded I got an answer back 
that this was out of scope of the draft. If I read ND Proxy I think that 
this case is illegal and that ND proxy processing will be disabled [ 2nd 
CLAT will receive an RA message with the P bit set on its upstream 
interface]

But there's no such explicit protection or detection of cascaded IANA 
assigned EUI-64 ID addresses in XLAT, which would definitely cause an 
IPv6 address conflict with the upstream CLAT. It strikes me as odd that 
ND Proxy goes to the trouble of detecting and shutting down the 2nd ND 
proxy if there's cascading, but XLAT BCP doesn't.

Why not explicitly shut down the affected functions of the downstream 
CLAT if it detects a duplicate IANA assigned EUI-64 address on it's 
upstream interface? Wouldn't that protect existing service from the 
upstream CLAT?

> Else if EUI-64 reserved address available, do that.

I have read 8.3.2 and it does not seem to be worded exactly as you suggest.

Currently it's worded in the negative "if cannot X then can Y", and in 
some places it doesn't even use reserved keywords in capitals.

That to me does not express a preference for good behaviour of an "if X 
then SHOULD Y else MAY Z ....." clause.

I'd prefer this section to be worded in the positive (this is Best 
Current Practice) to give the preferred translation order (exactly as 
you state, using if then else...  ), and thus avoid perpetuating bad 
practice of single /64 working, and ensure interoperability if devices 
are swapped out.

Here's my (non expert) version of the text:

In the case that DHCPv6-PD [RFC3633] is available, the CLAT SHOULD use a 
dedicated IPv6 prefix for stateless translation [RFC6145]. ND Proxy 
andIANA assigned EUI-64 ID based addresses SHOULD NOT be used.

If the CLAT does not have a dedicated IPv6 prefix available for 
translation, the CLAT SHOULD attempt to perform NAT44 and stateless 
translation [RFC6145] as detailed in the following paragraph.

IPv4 packets from the LAN SHOULD be translated using NAT44 to the 
private IPv4 host address of the CLAT that is not included in LAN 
segment of CLAT.  Then, the CLAT SHOULD perform a stateless translation 
[RFC6145] so that the IPv4 packets from the CLAT IPv4 host address are 
translated to the CLAT WAN IPv6 address as described in [RFC6145]. ND 
Proxy MAY be used. EUI-64 ID based addresses SHOULD NOT be used.

Please note that RFC 4389 section 4.1.3.3 
http://tools.ietf.org/html/rfc4389#section-4.1.3.3 prohibits a CLAT from 
performing ND Proxy if RA packets are received on the downstream interface.

When both DHCPv6-PD and ND proxy are not available a 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 
IANA assigned EUI-64 ID SHOULD NOT be used for L2 link addressing. 
Network operators SHOULD ensure that the upstream interface of each CLAT 
is connected to an unique upstream IPv6 prefix, to prevent potential 
problems with duplicate IPv6 addressing of downstream interfaces of two 
CLAT's connected in parallel,

I'm relying on you xlat experts to get the preference order right.....
> network.  While, at the same time, saying DHCP-PD is the best path
I appreciate the intention but I think the text could be improved.
> boundaries is one of their most active areas of research
As stated above I now think ND proxy should shut down when a phone using 
ND proxy is connected to Homenet. However, if two wireless devices are 
using CLAT + single /64 + ND Proxy at the moment one phone is tethered, 
wouldn't they both detect RA packets on their downstream interfaces, 
causing both to fail over to a different translation scheme (based on 
fixed IANA address)? This isn't such a crazy scenario: I know of places 
that deliver "fixed" domestic Internet links via wireless; as well as 
some friends who own more than one mobile device per household. Wouldn't 
this cause some interesting oscillation effects, as well as killing 
existing sessions?

> Ray Hunter <mailto:[email-masked]>
> 25 August 2012 21:27
> Specifically: According to BCP 157 RFC6177 "A key principle for 
> address management is that end sites always be able to obtain a 
> reasonable amount of address space for their actual and planned usage, 
> and over time ranges specified in years rather than just months."
>
> wireless LTE mobile phone acting as a CPE router (with built in CLAT 
> and special processing for single /64 working) is pretty likely to 
> connect into a Homenet in parallel to a domestic wired CPE router 
> (with built in CLAT).
>
> ------------------------------------------------------------------------

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 26 Aug 2012 20:05:22 +0000

I appreciate the downsides of ND proxy (and RA proxy or lack thereof), but it's usage is MUST for cellular networks until they move to rel 10, to carry on with the business without relying on IPv4 clutches. 

And it is ok for us protocol zealots  to discount any sub-optimal/imperfect approach because a better/optimal approach (e.g. PD) is on the way, but it is impractical for us to expect 'business' to wait until that happens. 

If we can't find an alternative solution that is deemed better in the _immediate _future, then let's proceed with what we have so far (and document appropriate gotchas). 

Cheers,
Rajiv

Sent from my Phone

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 26 Aug 2012 20:13:51 +0000

I agree to the intention of doing things right from the outset, but what if 'outset' is far off in the future (with a much bigger dependency) and the problem needs to be solved now in the current paradigm/networks ?

Cheers,
Rajiv

Sent from my Phone

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 26 Aug 2012 17:11:24 -0400

On 12-08-26 4:13 PM, "Rajiv Asati (rajiva)" <[email-masked]> wrote:

>I agree to the intention of doing things right from the outset, but what
>if 'outset' is far off in the future (with a much bigger dependency) and
>the problem needs to be solved now in the current paradigm/networks ?

The big issue now (my opinion) is getting IPv6 onto mobile networks- in
production.  Delays in getting it there will be a major setback for IPv6.
Right now, many mobile operators are faced with technical constraints on
what can be supported on the network.

To get IPv6 into production, we need to use what we have.  Cameron B noted
something important.  With NDProxy, we can change a tethered attachment
form no-IPv6 to IPv6 capable.  This is very important to getting things
moving in production networks.  I think waiting will insight operators to
go down paths (out of necessity) which may dial us back on the progress
wheel.

I have many devices which tether in my network, along with many gateway
like devices.  It would be a shame to not get IPv6 moving on this front
while we wait for DHCP-PD to be commercially ready.

Regards,

Victor Kuarsingh

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Sun, 26 Aug 2012 21:38:14 +0000

Hi Hemant,

I must be missing something. Could you please clarify why RFC4389 is not
good enough wrt the expected behavior of handling the RAs by the proxy ?

I understand why RA proxy by itself is not the full-proof solution (hence,
discounted early on), but that's why RFC4389 was put in place.

I am looking at the following sections and I am not seeing any technical
issue:
	- Section 4.1.3.3 ICMPv6 Router Advertisements
	- section-4.1.2 Proxying Packets
	- section 6 Loop Prevention

Cheers,
Rajiv

-----Original Message-----
From: "Hemant Singh   (shemant)" <[email-masked]>
Date: Saturday, August 25, 2012 3:54 PM
To: Cameron Byrne <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] single /64, ND Proxy, and
draft-ietf-v6ops-464xlat-07.txt

>It's comparing apples to oranges.  Dual-stack works.  The DHCPv6 PD is
>recommended by the IETF (at least for the IPv6 CPE router document) over
>a single /64 because a single /64 has issues supporting tethered clients
>while the DHCPv6 PD does not.
>
>
>Not quite.  rfc4389 is experimental because the protocol specified by the
>document has issues.  The issues were pointed out recently by me to
>v6ops.  See
>
>If one deploys a single /64 to a UE and the UE has to support tethered
>clients, the UE will have to proxy the RA.  How is the proxy RA
>implemented?  Note also, that is why the IPv6 protocol WG in 6man is
>standardizing a DAD proxy (draft-ietf-6man-dad-proxy) on standards track
>but not any ND Proxy which still stays as experimental.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 26 Aug 2012 22:41:51 +0000

See

Specifically see this text in my statements.

"Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in essence forwards IP (ND) packets without decrementing ttl, which can lead to catastrophic loops. The RFC tries to ameliorate that by detecting loops. However, the loop detection is based on receiving RAs (with the P-bit) which handles some cases. But it isn't robust against somebody connecting what was two Ethernet segments after ND proxy has sent its two P-bit RAs."

Hemant

-----Original Message-----
From: Rajiv Asati (rajiva) 
Sent: Sunday, August 26, 2012 5:38 PM
To: Hemant Singh (shemant); Cameron Byrne
Cc: [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

Hi Hemant,

Cheers,
Rajiv

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 26 Aug 2012 16:16:48 -0700

> "Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in essence forwards IP (ND) packets without decrementing ttl, which can lead to catastrophic loops. The RFC tries to ameliorate th…

This last sentence does not make sense to me, it is unclear exactly
what the problem is.  Are you going to deprecate ND Proxy in the IETF?
 As it is not yet deprecated, it is a valid tool.  If there is a
problem with ND Proxy, take it to 6man and hopefully it can be fixed.

Nonetheless,  i believe the concerns with ND Proxy are out of scope
for 464XLAT.  464XLAT has diagrams and scenarios about 3GPP and
wireline residential networks with a single router, the CLAT.  Without
better terms, these are "residential" or "consumer" services.  And,
specifically, ND Proxy is only used in the scenario where DHCP-PD is
not available.

We have documented what does work (running code blah blah blah...).

Yet, i see concerns about undefined scenarios not working.

CB

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 26 Aug 2012 23:28:24 +0000

Victor,

I agree with your sentiment.  However, I don't think the ND Proxy is a workable solution.  Have you or Cameron tested specifically for ND Proxy loops?  Just switch on and off, a few ND Proxy nodes and you will see the loops.  I for one, in wireline network, have already seen a catastrophic ND Proxy loop one year back where an IPv6 CPE router was using DHCPv6 PD and also supported an ND Proxy in the LAN segment of the CPE.  The CPE looped Proxied ND packets upstream to the SP which is catastrophic. 

As for the tethered service, I think, there are still large cellular operators in the U.S. who support the IPhone and not any tethering.  So why is a hack such as the ND Proxy being pushed for tethering?  Why not just add DHCPv6 PD to the UE and then the CLAT also uses a prefix from the DHCPv6 PD?  For IPv6, I think, it takes at least a few years for any service provider to shake out deployment testing.  We want to go down a ND Proxy path for few years and then support the DHCPv6 PD and disable ND Proxy on the UE?  Additionally, how is the CLAT UE going to sunset a single /64 and ND Proxy with DHCPv6 PD?  Is the UE hardware replaced totally or the UE undergoes a software upgrade?  What if the service provider has a mis-configuration in the DHCPv6 provisioning and the DHCPv6 PD fails and we know DHCPv6 tries forever?  Does the UE now move to enabling ND Proxy?   

Note, the additional benefit of adding the DHCPv6 PD to the UE is that a common testing body exists (the UNH) to test wireline IPv6 CPE routers and also a cellular UE that supports the DHCPv6 PD and an IPv6 CPE router.  Open WRT already exists as a Linux implementation for the UE vendors to leverage. 

The IETF has already endorsed the DHCPv6 PD over a single /64 and ND Proxy for rfc6205bis.  So why should the IETF even bother with a ND Proxy solution or block any operator from deploying the ND Proxy solution?  Go ahead and deploy the ND Proxy.  However remove the /64 section in section 8.3.2 from the xlat document and let's push the xlat document through the IETF with the DHCPv6 PD solution.  Removing section 8.3.2 also removes reserving an IID for use by CLAT.  I don't think we have any consensus on using reserved IID.

Regards back,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Kuarsingh
Sent: Sunday, August 26, 2012 5:11 PM
To: Rajiv Asati (rajiva); Mark ZZZ Smith
Cc: Ray Hunter; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

Regards,

Victor Kuarsingh

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 26 Aug 2012 20:04:26 -0400

Hamant,

On 12-08-26 7:28 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> 
>
>As for the tethered service, I think, there are still large cellular
>operators in the U.S. who support the IPhone and not any tethering.  So
>why is a hack such as the ND Proxy being pushed for tethering?

I cannot speak for every operator, but for some of us trying to deploy
IPv6, if I cannot do it with tethering, I cannot deploy it (part of the
service). Not supporting tethering would inhibit my ability to deploy (in
my case - perhaps for others).

>Why not just add DHCPv6 PD to the UE and then the CLAT also uses a prefix
>from the DHCPv6 PD?

I don't think anyone has said we don't want or agree with the use of
DHCP-PD.  The sentiment was related to the readiness of DHCP-PD in the
mobile environment.  This is related to when it was put into spec (3GPP
side) and then how long it took/takes to get it into production code, then
deployed.

>Additionally, how is the CLAT UE going to sunset a single /64 and ND
>Proxy with DHCPv6 PD?  Is the UE hardware replaced totally or the UE
>undergoes a software upgrade?  What if the service provider has a
>mis-configuration in the DHCPv6 provisioning and the DHCPv6 PD fails and
>we know DHCPv6 tries forever?  Does the UE now move to enabling ND Proxy?
> 

Sunsetting of the ND-Proxy is a concern.  I am not sure if this ranks
higher or lower then delaying IPv6 deployment.

> 
>
>Note, the additional benefit of adding the DHCPv6 PD to the UE is that a
>common testing body exists (the UNH) to test wireline IPv6 CPE routers
>and also a cellular UE that supports the DHCPv6 PD and an IPv6 CPE
>router.  Open WRT already exists as a Linux implementation for the UE
>vendors to leverage.
> 
>

I agree that DHCP-PD is preferential overall, but again, timing may be an
issue.  Also, many of us need to deal with challenges on the mobile side
which are above and beyond what I need to deal with on the wireline side.
I would have loved nothing less then to have my attachment capabilities
and timelines to be the same for both, but as the standards where written
and implemented, there was/is a gap.

At the end of the day, we will do what we need to do to get IPv6 service
up - whether or not is shows up in the document specifically.  Having it
in there however may be a better reflection [opinion alert] of what
operators will need to do to get the service into there networks (given I
don't think I am the only one with these challenges - albeit not every
mobile operation as you have noted)

Regards,

Victor K

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 27 Aug 2012 00:42:05 +0000

Hemant,

Thanks for the pointer, but it is still not clear

1) how the loop gets formed in a wireless network. Could you please help
me understand the 'loop' in this topology (UE1 has a p2p interface to R1,
and is configured for ND-proxy functionality):

ue11--LAN--_UE1_--WAN----R1
ue12--/

2) whether there are other issues besides loop possibility?

Cheers,
Rajiv

-----Original Message-----
From: "Hemant Singh   (shemant)" <[email-masked]>
Date: Sunday, August 26, 2012 6:41 PM
To: Rajiv Asati <[email-masked]>, Cameron Byrne <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [v6ops] single /64, ND Proxy, and

>³Issues with RFC 4389 such as weakness in loop avoidance. ND proxy in
>essence forwards IP (ND) packets without decrementing ttl, which can lead
>to catastrophic loops. The RFC tries to ameliorate that by detecting
>loops. However, the loop detection is based on receiving RAs (with the
>P-bit) which handles some cases. But it isn't robust against somebody
>connecting what was two Ethernet segments after ND proxy has sent its two
>P-bit RAs.²
>
>Hemant
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 01:09:52 +0000

Victor (and also replying to Rajiv in one email),

-----Original Message-----
From: Victor Kuarsingh [mailto:[email-masked]] 
Sent: Sunday, August 26, 2012 8:04 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>my case - perhaps for others).

Got it - you need tethering immediately.  Ok, back to the ND Proxy issues then.  

My wife turns on her cell phone and this CLAT phone uses the reserved IID and thus does not issue any RA with the ND Proxy P-bit.  A tethered client in a home IPv6 router uses the RA to get a SLAAC IPv6 address.  Behind the IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone that supports only an ND Proxy and a single /64.  Before my phone is able to send an RA with the P-bit set, the bridged behind home router looped my wife's phone RA to my phone and my phone loops the RA back to the SP.  Additionally, what does my tethered client do if the client receives two different RA's as described above and specifically how is proxying of NA's done?  Is the NA sent to the ND Proxy phone or the reserved IID phone when the tethered node has only one interface to receive an NS on?  

Soon as one says tethering, testing for what is working code is very broad because there could be whole network behind one tethered client.  This is the same point Ray Hunter is making and it would be good to reply to his email at the URL below.

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

Regards,

Hemant

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 26 Aug 2012 20:26:47 -0700

Hemant,

> My wife turns on her cell phone and this CLAT phone uses the reserved IID and thus does not issue any RA with the ND Proxy P-bit.  A tethered client in a home IPv6 router uses the RA to get a SLAAC…

So let me get the facts of your scenario correct:

There is a phone CLAT using reserved IID (the wife)

There is a home IPv6 router

There is a network bridge

There is a cell phone that support only ND Proxy with a /64

There is a race condition:   "Before my phone is able to send an RA
with the P-bit set, the bridged behind home router looped my wife's
phone RA to my phone and my phone loops the RA back to the SP."

My response is this:

1.  The 464XLAT I-D neither explicitly nor implicitly supports such a
network.  The 464XLAT service is "limited" and the scenarios described
in the text and diagrams of the I-D are simple and known to work
without harm.

2.  As a Mobile service provider, i do not support such a topology.
If a customer calls our call center and explains this setup ... it
will not get support.

3.  ND Proxy does not support this setup explicitly
http://tools.ietf.org/html/rfc4389#section-1.3

4. I don't think it is possible to instrument such a network as you
have described.  Phones that i am aware of are either "wifi router" or
"wifi client", but the scenario you described requires both phones to
be a "wifi router" since they are providing access to a mobile network
and at the same time "wifi clients" since they are joined to the home
router and home bridge.

5. FYI, at an implementation level, I believe the CLAT implementation
that is implemented today for Android (submitted code) will never
proxy an RA received on the LAN to the mobile network on the WAN.  The
WAN interface is defined and it is the WAN address that is shared to
the LAN, not the other way around.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 27 Aug 2012 06:11:59 +0200 (CEST)

On Sun, 26 Aug 2012, Hemant Singh (shemant) wrote:

> why is a hack such as the ND Proxy being pushed for tethering?  Why not 
> just add DHCPv6 PD to the UE and then the CLAT also uses a prefix from

That's easier said than done. We also need support in GGSN/PGW, which as 
Cameron said is a release 10 feature which I would imagine is 1-2 years 
off into the future (at least).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: jouni korhonen <[email-masked]>
Date: Mon, 27 Aug 2012 09:36:25 +0300

On Aug 27, 2012, at 4:09 AM, Hemant Singh (shemant) wrote:

> My wife turns on her cell phone and this CLAT phone uses the reserved IID and thus does not issue any RA with the ND Proxy P-bit.  A tethered client in a home IPv6 router uses the RA to get a SLAAC IPv6 address.  Behind the IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone that supports only an ND Proxy and a single /64.  Before my phone is able to send an RA with the P-bit set, the bridged behind home router looped my wife's phone RA to my phone and my phone loops the RA back to the SP.  Additionally, what does my

Your phone should then disable the proxy behavior according to 4.1.3.3 of RFC4389 (the second last para).
Anyway, the topology described here is out of scope of RFC4389 as far as I understand. Also, with the
current mobiles, I don't think being a STA and AP at the same time is possible, which seems to a
prerequisite for the above topology.

- Jouni

>  tethered client do if the client receives two different RA's as described above and specifically how is proxying of NA's done?  Is the NA sent to the ND Proxy phone or the reserved IID phone when the tethered node has only one interface to receive an NS on?

---

From: GangChen <[email-masked]>
Date: Mon, 27 Aug 2012 15:10:04 +0800

2012/8/27, Hemant Singh (shemant) <[email-masked]>:
> My wife turns on her cell phone and this CLAT phone uses the reserved IID
> and thus does not issue any RA with the ND Proxy P-bit.  A tethered client
> in a home IPv6 router uses the RA to get a SLAAC IPv6 address.  Behind the
> IPv6 CPE router is a network bridge. Subsequently, I turn on my cell phone
> that supports only an ND Proxy and a single /64.  Before my phone is able to
> send an RA with the P-bit set, the bridged behind home router looped my
> wife's phone RA to my phone and my phone loops the RA back to the SP.

I guess the scenairo is not "464xlat". You are entrying to another
topic(maybe call it nested-xlat more properly), which I believe is
going beyond current scope. the traget scenario is well described in
"BCP Scenario" and Figure1/2. Including the nested scenario would be
not draft's intention.

FWIW, replying to the comment "I don't think we have any consensus on
using reserved IID.", I think we are trying to figure out the
potential solution if single /64 allocated & No ND-proxy for almost a
half of month. But the outcome is nothing apart from Reserved IID (If
you have another one, please identify). Therefore, It's worth to
confirm CB's proposal for the sake of progress.  i.e.
http://www.ietf.org/mail-archive/web/v6ops/current/msg13955.html

Especially

>Else if EUI-64 reserved address available, do that.

BRs

Gang

> Additionally, what does my tethered client do if the client receives two
> different RA's as described above and specifically how is proxying of NA's
> done?  Is the NA sent to the ND Proxy phone or the reserved IID phone when
> the tethered node has only one interface to receive an NS on?

> Soon as one says tethering, testing for what is working code is very broad
> because there could be whole network behind one tethered client.  This is
> the same point Ray Hunter is making and it would be good to reply to his
> email at the URL below.
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Aug 2012 10:21:28 +0200

2012-08-25 22:40, Cameron Byrne :
...
> Else if EUI-64 reserved address available, do that.

1. DHCP-PD, if used with a /64, isn't exclusive of of the need to avoid Collision between the CLAT IID and host IIDs. (Independently of whether this avoidance is done with ND proxy or reserved EUI-64).

2. If ND proxy is used: (1) it has to be modified to exclude the CLAT IPv6 address although it isn't on any bridged link (RFC 4389, is for bridged links); (2) the problem remains of a host reserving the colliding IID before 464XLAT activation. Thus, using ND proxy isn't exclusive either of using the reserved EUI-64. 

These are reasons why, to keep independence of functions, section 8.3.2 can and should in my understanding be improved: before "the CLAT MAY use a dedicated IANA assigned EUI-64 ID for creating a translated IPv6 address to be used in stateless translation [RFC6145]", the restrictive condition should be deleted (that which says "if the CLAT cannot perform ND Proxy [RFC4389] due to the restriction of the implementation").

With this small amendment (which just avoids an artificial limitation of reserved EUI-64 applicability), time has come, IMHO, to publish the 464XLAT BCP, and deploy.

Best regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Aug 2012 17:54:49 +0900

Ok, so how about the following? Comments welcome.

0. If you get a DHCPv6 prefix delegation: congratulations. You live in the
glorious future. Your carrier has a release 10 network, and is providing
you with tethering (either because they're a just that nice, or because you
paid extra for the privilege). The CLAT simply behaves like an RFC 6204
router. Done.

Now for the rest of us. Since we're still here, it means we only have a
single /64. If you don't want to implement tethering, do nothing. If you do
want to implement tethering, proceed as follows (cell0 is the upstream
interface, wlan0 is the downstream):

1. Enable tethering only when cell0 is a point-to-point interface (e.g.,
3G, LTE, ...).
2. When enabling tethering, take the IPv6 address of cell0 (which you were
already using, and need to continue to use because you have open
connections to it), and assign it to wlan0 instead of cell0
3. Treat cell0 as unnumbered; when sending out packets, use the IP address
assigned to wlan0.
4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like a
standard IPv6 router (decrement TTL, etc.)
5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa like a
standard IPv6 multicast router (But I don't know anything about multicast,
so I'll shut up now.)
6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, they
will fail DAD.

So far so good. There is no bridging, and since the upstream is a
point-to-point interface, there are no loops. Note that this is *not* RFC
4389. But it does not need to be.

We haven't talked about CLAT yet. There are two cases here:

1. The CLAT implementation can use the same IPv6 address as the phone. In
this case, no problem.
2. The CLAT implementation cannot use the same IPv6 address as the phone.
In this case, either:
  a) the CLAT does DAD for that other address as well, or:
  b) picks an address that "shouldn't collide" (remi's reserved IID)

It's as simple as that. So, as far as I can see, the only issue left to
discuss is "do we do 2a or 2b"?

On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant)
<[email-masked]>wrote:

> that supports only an ND Proxy and a single /64.  Before my phone is able
> to send an RA with the P-bit set, the bridged behind home router looped my

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2012 11:14:01 +0200

Le 27/08/2012 10:54, Lorenzo Colitti a écrit :
> 0. If you get a DHCPv6 prefix delegation: congratulations. You live in
> the glorious future. Your carrier has a release 10 network, and is
> providing you with tethering (either because they're a just that nice,
> or because you paid extra for the privilege). The CLAT simply behaves
> like an RFC 6204 router. Done.
>
> single /64. If you don't want to implement tethering, do nothing. If you
> do want to implement tethering, proceed as follows (cell0 is the
> upstream interface, wlan0 is the downstream):
>
> 2. When enabling tethering, take the IPv6 address of cell0 (which you
> were already using, and need to continue to use because you have open

I wonder what breaks if one assigns the same address to two different 
interfaces (be them of same machine).

> 3. Treat cell0 as unnumbered; when sending out packets, use the IP
> address assigned to wlan0.
> 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like
> a standard IPv6 router (decrement TTL, etc.)
> 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa
> like a standard IPv6 multicast router (But I don't know anything about
> multicast, so I'll shut up now.)
> 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you,
> they will fail DAD.

Sounds logic.

Alex

> point-to-point interface, there are no loops. Note that this is *not*
> RFC 4389. But it does not need to be.
>
> 1. The CLAT implementation can use the same IPv6 address as the phone.
> In this case, no problem.
> 2. The CLAT implementation cannot use the same IPv6 address as the
> phone. In this case, either:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     From: Victor Kuarsingh [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     Cc: [email-masked] <mailto:[email-masked]>
>     My wife turns on her cell phone and this CLAT phone uses the
>     reserved IID and thus does not issue any RA with the ND Proxy P-bit.
>       A tethered client in a home IPv6 router uses the RA to get a SLAAC
>     IPv6 address.  Behind the IPv6 CPE router is a network bridge.
>     Subsequently, I turn on my cell phone that supports only an ND Proxy
>     and a single /64.  Before my phone is able to send an RA with the
>     P-bit set, the bridged behind home router looped my wife's phone RA
>     to my phone and my phone loops the RA back to the SP.  Additionally,
>     what does my tethered client do if the client receives two different
>     RA's as described above and specifically how is proxying of NA's
>     done?  Is the NA sent to the ND Proxy phone or the reserved IID
>     phone when the tethered node has only one interface to receive an NS on?
>
>     Soon as one says tethering, testing for what is working code is very
>     broad because there could be whole network behind one tethered
>     client.  This is the same point Ray Hunter is making and it would be
>     good to reply to his email at the URL below.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Aug 2012 11:28:39 +0200

Le 2012-08-27 à 10:54, Lorenzo Colitti a écrit :

> 0. If you get a DHCPv6 prefix delegation: congratulations. You live in the glorious future. Your carrier has a release 10 network, and is providing you with tethering (either because they're a just that nice, or because you paid extra for the privilege). The CLAT simply behaves like an RFC 6204 router. Done.
> 
> Now for the rest of us. Since we're still here, it means we only have a single /64. If you don't want to implement tethering, do nothing. If you do want to implement tethering, proceed as follows (cell0 is the upstream interface, wlan0 is the downstream):
> 
> 1. Enable tethering only when cell0 is a point-to-point interface (e.g., 3G, LTE, ...).
> 2. When enabling tethering, take the IPv6 address of cell0 (which you were already using, and need to continue to use because you have open connections to it), and assign it to wlan0 instead of cell0
> 3. Treat cell0 as unnumbered; when sending out packets, use the IP address assigned to wlan0.
> 4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa like a standard IPv6 router (decrement TTL, etc.)
> 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa like a standard IPv6 multicast router (But I don't know anything about multicast, so I'll shut up now.)
> 6. Send an RA for the /64 to wlan0. If hosts pick the same IID as you, they will fail DAD.
> 
> So far so good. There is no bridging, and since the upstream is a point-to-point interface, there are no loops. Note that this is *not* RFC 4389. But it does not need to be.
> 
> 1. The CLAT implementation can use the same IPv6 address as the phone. In this case, no problem.
> 2. The CLAT implementation cannot use the same IPv6 address as the phone. In this case, either: 
> It's as simple as that. So, as far as I can see, the only issue left to discuss is "do we do 2a or 2b"?

Although I may not follow all details, this seems clear enough.

Now, 2b has the advantage that it solves the problem of hosts whose IIDs are assigned before CLAT activation.  Since it can be combined with the extended DAD above, or with ND proxy if used, it is clear that nothing is lost with it.

This IMHO justifies to at least let vendors use 2b if they want, and even 2a and 2b simultaneously if they prefer . (The proposed amendment for this is in my last email to Cameron.)
By leaving the market decide which combination to use, this BCP can be published, at last. And 464XLAT can be deployed.

Regards,
RD

> 
> On Mon, Aug 27, 2012 at 10:09 AM, Hemant Singh (shemant) <[email-masked]> wrote:

---

From: Gert Doering <[email-masked]>
Date: Mon, 27 Aug 2012 11:50:01 +0200

Hi,

On Sun, Aug 26, 2012 at 11:28:24PM +0000, Hemant Singh (shemant) wrote:
> The CPE looped Proxied ND packets upstream to the SP which is catastrophic.

If that is "catastrophic", something in the SP network is horribly
wrong.

You have to expect all sort of funny and broken packets from the customer
side.  If anything coming from the customer is breaking the SP network,
it was broken before, you just didn't notice it yet.

(Like: missing customer-to-customer isolation, or accepting RAs from
customers)

> As for the tethered service, I think, there are still large
> cellular operators in the U.S. who support the IPhone and not any
> tethering.  

As the iPhone does not support any IPv6 on the 3G side, this is fully
irrelevant for a discussion about code that exists *today*.

To repeat: Cameron is presenting a solution for *todays* networks that
works with *todays* UEs.  Don't delay this much needed solutions by
worrying about that it might not work in completely different circumstances.

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 27 Aug 2012 02:50:20 -0700 (PDT)

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: Hemant Singh (shemant) <[email-masked]> 
>Sent: Monday, 27 August 2012 6:54 PM

I think the above is a good idea. Perhaps rather than moving the address from the cell0 to wlan0 interface, the cell0 interface could be permanently unnumbered, and loopback or similar virtual interface is assigned an address from within the /64, and is a member of a bridge. The wlan0 interface is added or removed from the bridge as tethering is enabled and disabled.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Aug 2012 18:50:36 +0900

On Mon, Aug 27, 2012 at 6:28 PM, Rémi Després <[email-masked]>wrote:

> 5. Forward IPv6 multicast packets from wlan0 to cell0 and vice versa like
> a standard IPv6 multicast router (But I don't know anything about
> Now, 2b has the advantage that it solves the problem of hosts whose IIDs
> are assigned before CLAT activation.  Since it can be combined with the
> extended DAD above, or with ND proxy if used, it is clear that nothing is
> lost with it.
>
> This IMHO justifies to at least let vendors use 2b if they want, and even
> 2a and 2b simultaneously if they prefer . (The proposed amendment for this
> is in my last email to Cameron.)
> By leaving the market decide which combination to use, this BCP can be
> published, at last. And 464XLAT can be deployed.
>
> Regards,
> RD
>

Remi,

we already know you think 2b is better.But I don't want to get into whether
to do 2a or 2b; we are discussing that in another thread. This thread is
about whether to support tethering using a single /64, and how to do it.

Cheers,
Lorenzo

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2012 11:58:54 +0200

Le 27/08/2012 11:50, Lorenzo Colitti a écrit :
>
>
> On Mon, Aug 27, 2012 at 6:28 PM, Rémi Després <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>>     0. If you get a DHCPv6 prefix delegation: congratulations. You
>>     live in the glorious future. Your carrier has a release 10
>>     network, and is providing you with tethering (either because
>>     they're a just that nice, or because you paid extra for the
>>     privilege). The CLAT simply behaves like an RFC 6204 router. Done.
>>
>>     Now for the rest of us. Since we're still here, it means we only
>>     have a single /64. If you don't want to implement tethering, do
>>     nothing. If you do want to implement tethering, proceed as follows
>>     (cell0 is the upstream interface, wlan0 is the downstream):
>>
>>     2. When enabling tethering, take the IPv6 address of cell0 (which
>>     you were already using, and need to continue to use because you
>>     have open connections to it), and assign it to wlan0 instead of cell0
>>     4. Forward IPv6 unicast packets from wlan0 to cell0 and vice versa
>>     like a standard IPv6 router (decrement TTL, etc.)
>>     5. Forward IPv6 multicast packets from wlan0 to cell0 and vice
>>     versa like a standard IPv6 multicast router (But I don't know
>>     anything about multicast, so I'll shut up now.)
>>     point-to-point interface, there are no loops. Note that this is
>>     *not* RFC 4389. But it does not need to be.
>>
>     Now, 2b has the advantage that it solves the problem of hosts whose
>     IIDs are assigned before CLAT activation.  Since it can be combined
>     with the extended DAD above, or with ND proxy if used, it is clear
>     that nothing is lost with it.
>
>     This IMHO justifies to at least let vendors use 2b if they want, and
>     even 2a and 2b simultaneously if they prefer . (The proposed
>     amendment for this is in my last email to Cameron.)
>     By leaving the market decide which combination to use, this BCP can
>     be published, at last. And 464XLAT can be deployed.
>
>     Regards,
>     RD
>
>
> Remi,
>
> we already know you think 2b is better.But I don't want to get into
> whether to do 2a or 2b; we are discussing that in another thread. This
> thread is about whether to support tethering using a single /64, and how
> to do it.

There is an alternate possibility where one extracts two different 
prefixes out of the /64 (a /65 and a /66) and uses DHCP to configure the 
clients behind.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Aug 2012 19:00:25 +0900

On Mon, Aug 27, 2012 at 6:50 PM, Mark ZZZ Smith
<[email-masked]>wrote:

> I think the above is a good idea. Perhaps rather than moving the address
> from the cell0 to wlan0 interface, the cell0 interface could be permanently
> unnumbered, and loopback or similar virtual interface is assigned an
> address from within the /64, and is a member of a bridge. The wlan0
> interface is added or removed from the bridge as tethering is enabled and
> disabled.

One of the reasons I suggest we don't do bridging is that bridges forward
broadcasts and ND packets, and that can cause various nastiness. I think
routing is much simpler, and if you don't want to move the IPv6 address
from cell0 to wlan0 all you need to do is send proxy NAs for your own
address (note - this *is different* from ND proxy as defined in RFC 4389).

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Aug 2012 12:13:39 +0200

Le 2012-08-27 à 11:50, Lorenzo Colitti a écrit :

> 
> 
> On Mon, Aug 27, 2012 at 6:28 PM, Rémi Després <[email-masked]> wrote:
> 
> we already know you think 2b is better.But I don't want to get into whether to do 2a or 2b; we are discussing that in another thread. 

> This thread is about whether to support tethering using a single /64, and how to do it.

Fair enough.
/64 tethering support? YES, it can work, and therefore must be a possible deployment scenario where UEs are assigned /64s.

Note however that saying "the only issue left to discuss is 'do we do 2a or 2b'" is more restrictive than needed: they can be used simultaneously.

RD

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 27 Aug 2012 13:23:17 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Monday, August 27, 2012 11:14 AM
> To: [email-masked]

As I understood it, Lorenzo is proposing to move the IPv6 address from
cell0 to wlan0 and leave cell0 with LLA only and rely on rfc3484 to pick
the right source address. SLAAC would need to be disabled on cell0 
(for the time tethering is ON) as the packet core gw will be sending RAs.

fyi. the packet core gw is not allowed to use any ip address out of /64
for its interface, so the /64 is fully owned by the UE
 
> > discuss is "do we do 2a or 2b"?

Cheers,
Ales

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2012 13:56:46 +0200

Le 27/08/2012 13:23, Vízdal Aleš a écrit :
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
>> Sent: Monday, August 27, 2012 11:14 AM To: [email-masked] Subject:
>>  Re: [v6ops] single /64, ND Proxy, and
>>>  nothing. If you do want to implement tethering, proceed as
>>> follows (cell0 is the upstream interface, wlan0 is the
>>> downstream):
>>>
>>> 1. Enable tethering only when cell0 is a point-to-point interface
>>> (e.g., 3G, LTE, ...). 2. When enabling tethering, take the IPv6
>>> address of cell0 (which you were already using, and need to
>>> continue to use because you have open connections to it), and
>>> assign it to wlan0 instead of cell0
>>
>> I wonder what breaks if one assigns the same address to two
>> different interfaces (be them of same machine).
>
> As I understood it, Lorenzo is proposing to move the IPv6 address
> from cell0 to wlan0 and leave cell0 with LLA only and rely on rfc3484
> to pick the right source address.

This looks advantageous for the common case of a UE with one wlan0 and a
single subnet behind it.

I wonder whether this would work when there is bt0 in addition to wlan0
and cell0.  Put the operator-assigned address on both wlan0 and bt0?

> SLAAC would need to be disabled on cell0 (for the time tethering is
> ON) as the packet core gw will be sending RAs.

Ok, makes sense.

(but in my setting the packet core gw is not sending RAs although it
does negotiate an IPv6 address with UE, and works as default router).

> fyi. the packet core gw is not allowed to use any ip address out of
> /64 for its interface, so the /64 is fully owned by the UE

Is one sure that the packet core gw is not allowed to use any IP address
out of that /64?  (I mean there may exist some spec saying so?)

Yours,

Alex

>>> 3. Treat cell0 as unnumbered; when sending out packets, use the
>>> IP address assigned to wlan0. 4. Forward IPv6 unicast packets
>>> from wlan0 to cell0 and vice versa like a standard IPv6 router
>>> (decrement TTL, etc.) 5. Forward IPv6 multicast packets from
>>> wlan0 to cell0 and vice versa like a standard IPv6 multicast
>>> router (But I don't know anything about multicast, so I'll shut
>>> up now.) 6. Send an RA for the /64 to wlan0. If hosts pick the
>>> same IID as you, they will fail DAD.
>>
>> Sounds logic.
>>
>> Alex
>>
>>>
>>> So far so good. There is no bridging, and since the upstream is
>>> a point-to-point interface, there are no loops. Note that this is
>>> 1. The CLAT implementation can use the same IPv6 address as the
>>> phone. In this case, no problem. 2. The CLAT implementation
>>> cannot use the same IPv6 address as the phone. In this case,
>>> either: a) the CLAT does DAD for that other address as well, or:
> Cheers, Ales

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 12:25:35 +0000

Lorenzo

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, August 27, 2012 6:00 AM
To: Mark ZZZ Smith
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>One of the reasons I suggest we don't do bridging is that bridges forward broadcasts and ND packets, and that can cause various nastiness. I think routing is much simpler, and if you don't want to >move the IPv6 address from cell0 to wlan0 all you need to do is send proxy NAs for your own address (note - this *is different* from ND proxy as defined in RFC 4389).

Thanks for the details in your other email.  The UE will still need to proxy the RA from the service provider to the wlan0 segment of the UE.  Further an NS arrives at cell0 from the service provider.   The UE will also have to proxy this NS.  Thus there is no getting around the ND Proxy.

Hemant

---

From: jouni korhonen <[email-masked]>
Date: Mon, 27 Aug 2012 15:34:41 +0300

> out of that /64?  (I mean there may exist some spec saying so?)

Ales refers here to 3GPP GGSN/PGW, which has this restriction. See
RFC6459 Section 5.2 (paragraph 3).

- Jouni

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 27 Aug 2012 14:55:56 +0200

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Monday, August 27, 2012 2:26 PM
To: Lorenzo Colitti; Mark ZZZ Smith
Cc: [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

Lorenzo

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, August 27, 2012 6:00 AM
To: Mark ZZZ Smith
Cc: Hemant Singh (shemant); [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

The UE might need to proxy the RS from the LAN to the 3GPP link as the 3GPP specs are proposing tuning the RA interval to ~4hrs after few initial messages. Or the UE would need to be sending the RA on behalf of the SP. Speaking about the 3GPP GGSN/PDN-GW
I wonder if the GGSN/PDN-GW needs to do NS/NA as the 3GPP link is a p2p link, so the GGSN/PDN-GW will send anything that belongs to /64 down to the UE. (but I might need to think more about it)

Hemant

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Mon, 27 Aug 2012 15:21:26 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
> ZZZ Smith
> Sent: Sunday, August 26, 2012 3:38 AM
> To: Cameron Byrne; Ray Hunter
> Cc: [email-masked]
> Temporary work-arounds have a horrible habit of becoming permanent work-arounds,
> and their temporary disadvantages then become permanent ones. If DHCPv6-PD is the
> proper solution, then I don't think anything else should be acceptable. The requirement
> for DHCPv6-PD support will create the demand for DHCPv6-PD to then be widely
> implemented.

It seems to me that the discussion is no longer about XLAT, but about the usage of the ND Proxy
feature. Let me respond as a mobile operator. The benefit (I see) the ND Proxy can provide is 
decoupling of a Prefix Delegation readiness of a Mobile Network and a UE. So a customer can do 
tethering using IPv6 before the Prefix Delegation will be widely available using the Mobile Network 
that can provide him/her with IPv6 connectivity.

Cheers,
Ales

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Aug 2012 22:28:58 +0900

On Mon, Aug 27, 2012 at 9:25 PM, Hemant Singh (shemant)
<[email-masked]>wrote:

>  Lorenzo****
>
> ** **
>
> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Monday, August 27, 2012 6:00 AM
> *To:* Mark ZZZ Smith
> *Cc:* Hemant Singh (shemant); [email-masked]
>
> *Subject:* Re: [v6ops] single /64, ND Proxy, and
> draft-ietf-v6ops-464xlat-07.txt****
>
>  ** **
>
> >One of the reasons I suggest we don't do bridging is that bridges
> forward broadcasts and ND packets, and that can cause various nastiness. I
> think routing is much simpler, and if you don't want to >move the IPv6
> address from cell0 to wlan0 all you need to do is send proxy NAs for your
> own address (note - this *is different* from ND proxy as defined in RFC
> 4389).****
>
> ** **
>
> Thanks for the details in your other email.  The UE will still need to
> proxy the RA from the service provider to the wlan0 segment of the UE.
>

No, the UE needs to *send* an RA to its clients. It doesn't have to proxy
the one that comes from upstream.

>   Further an NS arrives at cell0 from the service provider.   The UE will
> also have to proxy this NS.  Thus there is no getting around the ND Proxy.
>

The network should not send NS packets to the UE. The 3GPP specs are very
clear that the handset is allowed to pick any IID on the link that it
wants. The only sane way to do this without blowing up state in the network
is to route the whole /64 to the handset.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 27 Aug 2012 22:31:57 +0900

> interface is added or removed from the bridge as tethering is enabled and

You don't need to move it. You can assign it to both interfaces if you want
(at least, you can do that on Linux).

---

From: jouni korhonen <[email-masked]>
Date: Mon, 27 Aug 2012 16:40:31 +0300

> I wonder if the GGSN/PDN-GW needs to do NS/NA as the 3GPP link is a p2p link, so the GGSN/PDN-GW will send anything that belongs to /64 down to the UE. (but I might need to think more about it)

I have never seen a NS coming from GGSN/PGW, though I cannot speak for all
possible boxes out there. Anyway, since 3GPP has no link-layer addresses
and generally there is no need for DAD, the only good reason for NS/NA would
be NUD. 3GPP specs are rather clear that the GGSN/PGW (or the rest of the
system) does not care about the IID for GUAs, thus the GGSN/PGW just pumps
always the whole /64 to the UE without any further ND procedures.. at least
the implementations I know of.

- Jouni

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 13:59:06 +0000

Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 9:29 AM
To: Hemant Singh (shemant)
Cc: Mark ZZZ Smith; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>No, the UE needs to *send* an RA to its clients. It doesn't have to proxy the one that comes from upstream.

 *send* totally involves an RA proxy operation.   Here is why.  The UE has received an RA on cell0 from the SP.   This RA causes the UE to *send* and RA on the wlan0 link.  The RA issued on the wlan0 link has to use a different link-layer header and copy all the SP RA parameters such a Router Lifetime to transmit the RA on the wlan0.   Using a different link-layer header on an ND message is the guts of any ND Proxy operation. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 14:00:47 +0000

Jouni & Cameron,

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 2:36 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>Your phone should then disable the proxy behavior according to 4.1.3.3 of RFC4389 (the second last para).

In 60 minutes (as per RFC 4389) my phone disables ND Proxy when the phone needs ND Proxy with a /64 assigned to the phone.  My phone tethering support is not available any more.  Now I have an attack vector to shutdown the ND Proxy of the phone and disable the tethering support of the phone. 

>prerequisite for the above topology.

Each of the two phones in my example, by itself, complies to the xlat document and also the RFC 4389.  It is perfectly reasonable to have both phones enabled at the same time but powered on at different times.  Then any mis-configured tethered network can disrupt network services of one of the phones or both.  We should caution use of the ND Proxy.  Here is some proposed text to add to section 8.3.2 of the xlat document

"Note any loop in the tethered network may cause the ND Proxy on the UE to be disabled." 

Thanks and regards,

Hemant

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 27 Aug 2012 07:04:31 -0700

On Mon, Aug 27, 2012 at 1:54 AM, Lorenzo Colitti <[email-masked]> wrote:
> glorious future. Your carrier has a release 10 network, and is providing you
> with tethering (either because they're a just that nice, or because you paid
> extra for the privilege). The CLAT simply behaves like an RFC 6204 router.
> Done.
>
> already using, and need to continue to use because you have open connections
> to it), and assign it to wlan0 instead of cell0

This is all fine, but this is not a draft about how to make tethering
work on a mobile network.

One of the assumption is that tethering does work and that ND Proxy or
similar mechanisms for /64 WAN interface sharing exists (they do), and
consequently how does the CLAT work in this environment?

That said, i like what you wrote, but it seems like implementation
details that are not needed for this draft.

Perhaps the draft should not just refer to ND Proxy but "ND Proxy and
other /64 sharing approaches"

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Aug 2012 00:02:45 +0900

On Mon, Aug 27, 2012 at 10:59 PM, Hemant Singh (shemant)
<[email-masked]>wrote:

>  *send* totally involves an RA proxy operation.   Here is why.  The UE has
> received an RA on cell0 from the SP.   This RA causes the UE to *send* and
> RA on the wlan0 link.  The RA issued on the wlan0 link has to use a
> different link-layer header and copy all the SP RA parameters such a Router
> Lifetime to transmit the RA on the wlan0.   Using a different link-layer
> header on an ND message is the guts of any ND Proxy operation.
>

Nope. It doesn't need to preserve the parameters. In fact, things really
wouldn't work well if it did. For example, the CLAT will almost certainly
want to change the interval between RAs (the default in the 3GPP spec is
one RA every 4.5 hours). It will probably want to include a the link-layer
address option. It might want to set the M bit if it has a DHCPv6 server.
And so on.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Aug 2012 00:04:44 +0900

> other /64 sharing approaches"

ND proxy a) is experimental b) doesn't solve the problem completely and c)
has issues with loops and the like. If the upstream is a p2p interface, you
can do tethering in other ways, like I described above.

Does ND proxy need to be specified at all in this doc? Can we get away with
just removing it?

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 27 Aug 2012 08:16:46 -0700

On Aug 27, 2012 8:05 AM, "Lorenzo Colitti" <[email-masked]> wrote:
> ND proxy a) is experimental b) doesn't solve the problem completely and
c) has issues with loops and the like. If the upstream is a p2p interface,
you can do tethering in other ways, like I described above.
>
> Does ND proxy need to be specified at all in this doc? Can we get away
with just removing it?

I thinking about it, i think we can leave out ND Proxy if we can describe
generically solutions that extend the /64 from WAN to LAN and leave the
details to the implementers.

Saying dhcp-pd only is not acceptable.

CB

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 15:17:16 +0000

Cameron,

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 10:05 AM
To: Lorenzo Colitti
Cc: Hemant Singh (shemant); [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>This is all fine, but this is not a draft about how to make tethering work on a mobile network.

Great.  Also note, most details Lorenzo has provided are already covered in RFC 6204 or RFC 6204bis.  That is another reason not to cover them in the xlat document. RFC6204 for the DSL Broadband Forum supports a unnumbered WAN including any Loopback interface to source packets out the WAN of the CPE router.   

>other /64 sharing approaches"

Right - we should re-work section 8.3.2 of the xlat document.  This is a xlat document that folks have expressed a need to get out fast for an RFC.  Thus we should not de-focus the document process with how the CLAT gets a /64 prefix to source packets used by the XLATE protocol.  During early revisions of RFC 6404 when the I-D included the 3GPP single /64 use case and ND Proxy, we were told by a v6ops Chair and other folks in the IESG that a v6ops document cannot reference an Experimental RFC.  You will, likely, face the same issue in the IESG with the xlat document if xlat continues to reference the ND Proxy RFC. 

Additionally, if the ND Proxy Experimental RFC is taken to re-work in 6man, at least one year will transpire before a new RFC that fixes all cases causing loops with RFC 4389.  Protocol work tends to step gingerly.  The other issue with RFC 4389 is that the RFC also needs to support SEND (RFC 3971).  I don't think any complete fix to the ND Proxy RFC is less than two years away.

The other sharing approach covered in section 8.3.2 is a reserved IID which is also taking longer to flush out text for and delaying the xlat document.  We could consider being silent on a reserved IID and also edit the IANA Considerations section.

One additional comment.  Why does the document in several places including section 8.3.2 include this text:

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

First, please define what is "Pref64:/n" somewhere in the document.  Is this a global IPv6 subnet prefix and what does the PLAT use this prefix for?  Then why does the CLAT have a "MAY" need to discover this prefix?

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 15:51:38 +0000

Lorenzo,

Sent: Monday, August 27, 2012 11:03 AM

>Nope. It doesn't need to preserve the parameters. 

Ok.  The two basic operations of a ND Proxy are to (a)  being able to sniff all multicast packets (by default, an IPv6 node does not sniff all multicast packets, and (b) write a new link-layer address in proxied messages.  Both operations are invoked on the RA received on the cell0 link before an RA is issued on the wlan0 link.

>In fact, things really wouldn't work well if it did. For example, the CLAT will almost certainly want to change the interval between RAs (the default in >the 3GPP spec is one RA every 4.5 hours). It will probably want to include a the link-layer address option. It might want to set the M bit if it has a >DHCPv6 server. And so on.

There is a third operation in the ND Proxy as specified in RFC 4389.  The RA is proxied as is to other interface(s) on creating a new link-layer for the packet.  That is where you have a good catch in that the RA parameters change from the SP RA to the RA issued on the wlan0 link.  Thus if the xlat document continues to reference RFC 4389, then the xlat document also has to address this caveat on the ND Proxy behavior.  Also a v6ops document does not specify any new protocol behavior.  Now we have another reason to elide the RFC 4389 reference from the xlat document.
 
It also seems like the cellular requirements are being flushed out as we speak.  Thus the xlat document can get delayed further.  Let's filter out any new requirement that involve the ND Proxy or any prefix configuration on the UE. Such requirements do not affect the xlat directly. 

The ND Proxy delayed my review of the xlat document.  Outside of the ND Proxy, I may have minor comments which I will send out in a day or two.  I am on PTO for this whole week but replying to some emails. 

Thanks all.

Hemant

---

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

> Additionally, if the ND Proxy Experimental RFC is taken to re-work in 6man, at least one year will transpire before a new RFC that fixes all cases causing loops with RFC 4389.  Protocol work tends…

+1 to avoid ND-proxy reference in section 8.3.2.

> The other sharing approach covered in section 8.3.2 is a reserved IID which is also taking longer to flush out text for and delaying the xlat document.

Following the separate discussion on the reserved IID, there remains no technical argument against it, especially with a MAY.
OTOH, if an exclusive /64 routed to a CLAT node, it clearly avoids the need for any specific provision against RFC4291-compliant hosts using the /64 to collide with the CLAT IPv6 address. (Neither DAD complement nor ND proxy is needed.)

Deleting it would therefore be a step backward, justified only by historical and undeserved FUD, against a feature already tested with running code. 

Regards,
RD

>  We could consider being silent on a reserved IID and also edit the IANA Considerations section.
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 27 Aug 2012 13:10:46 -0700 (PDT)

Hi,

>Cc: Hemant Singh (shemant) <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, 27 August 2012 8:00 PM
>On Mon, Aug 27, 2012 at 6:50 PM, Mark ZZZ Smith <[email-masked]> wrote:
>
>One of the reasons I suggest we don't do bridging is that bridges forward broadcasts and ND packets, and that can cause various nastiness. I think routing is much simpler, and if you don't want to move the IPv6 address from cell0 to wlan0 all you need to do is send proxy NAs for your own address (note - this *is different* from ND proxy as defined in RFC 4389).
>
>
>

Actually, I wasn't suggesting bridging over routing, just instead using a bridge virtual interface to avoid moving the address to and from the unnumbered link traffic source interface to the wlan0 interface e.g.

untethered:

[root@opy mark]# brctl show
bridge namebridge idSTP enabledinterfaces
br08000.000000000000no
[root@opy mark]#

[root@opy mark]# ip addr show dev br0
13: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN 
    link/ether 22:56:fd:56:39:87 brd ff:ff:ff:ff:ff:ff
    inet6 2001:db8::3496/64 scope global dynamic 
       valid_lft 7192sec preferred_lft 3592sec
    inet6 fe80::2056:fdff:fe56:3987/64 scope link 
       valid_lft forever preferred_lft forever
[root@opy mark]# 

tethered:

[root@opy mark]# brctl show
bridge namebridge idSTP enabledinterfaces
br08000.000000000000nowlan0
[root@opy mark]#

It may even be better to permanently leave wlan0 in the bridge instance, and use the interface's administrative state to enable or disable tethering.

(perhaps a bit down in the detail for this thread, however I think it does show that what you're proposing could be done today with existing deployed mechanisms)

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 27 Aug 2012 21:41:21 +0000

Cameron (and other authors of the xlat doc),

Some comments are included below. We do have to decide one last sticking point which is the use of the reserved IID or not.  If any hosts in the LAN are active before the CLAT is, when the CLAT is operational, and any LAN host needs tethering to the CLAT, just reset the host to perform new IPv6 address acquisition.  DAD will deal with any IPv6 address clash.  More details on DAD are included below.

COMMENT #1. Section 8.3.1.  Please change 

OLD
----

>From the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to

To

NEW
----

>From the delegated DHCPv6 [RFC3633] prefix, a /64 prefix is dedicated to

COMMENT #2. Here is a stab at a re-worked section 8.3.2.

OLD
-----

8.3.2.  Case of enabling NAT44 and stateless XLATE on CLAT

   In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may
   not have a dedicated IPv6 prefix for translation.  If the CLAT does
   not have a dedicated IPv6 prefix for translation, the CLAT can
   perform NAT44 and stateless translation [RFC6145].

   IPv4 packets from the LAN are NAT44 to the private IPv4 host address
   of the CLAT that is not included in LAN segment of CLAT.  Then, the
   CLAT will do a stateless translation [RFC6145] so that the IPv4
   packets from the CLAT IPv4 host address are translated to the CLAT
   WAN IPv6 address as described in [RFC6145].

   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.

NEW
----

8.3.2.  Case of enabling NAT44 and stateless XLATE on CLAT

   In the case that DHCPv6-PD [RFC3633] is not available, the CLAT may
   not have a dedicated IPv6 prefix for translation.  If the CLAT does
   not have a dedicated IPv6 prefix for translation, the CLAT
   performs NAT44 and stateless translation [RFC6145].

   IPv4 packets from the LAN are NAT44 translated to IPv4 address of the CLAT.  
   Thereafter, CLAT performs a stateless translation [RFC6145] using the IPv4 
   and the WAN IPv6 address of the CLAT as described in [RFC6145].
   
   The CLAT uses an ND Proxy to share the single /64 prefix between the LAN
   and WAN segments.  Additionally, it is expected the hosts in the LAN
   segment of the CLAT are reset for new IPv6 address acquisition if
   the hosts were active before the CLAT was operational in the LAN segment.
   
The idea is when the CLAT is booted and is operational, the CLAT user resets his/her IPv6 hosts if the hosts were already booted up and ready with an IPv6 link-local address.  Thus ND DAD operation will take over and detect any duplicates in the LAN.  If a duplicate is detected in the LAN and the duplicate matches the IPv6 link-local of the CLAT LAN interface, and if the link-local address is created using a globally unique IID using a mechanism such as the EUI-64, the IP operations on both nodes stop.  For other types of IPv6 addresses, the tentative address is used and a receiver of the DAD duplicate message logs a system management message.  

My personal vote is to have the CLAT LAN win if a DAD duplicate is detected in that the CLAT LAN continues with IPv6 operations and the LAN host is denied.  However, this is new behavior above and beyond RFC 4862.  A v6ops document cannot specify new protocol behavior.   However, I still do not like the special-case of reserved IID because then the SP IPv6 nodes also change to special-case the new reserved IID.  So now what do we do?  

Hemant

-----Original Message-----
From: Rémi Després [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 12:11 PM
To: Hemant Singh (shemant)
Cc: Cameron Byrne; Lorenzo Colitti; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Aug 2012 00:47:54 +0200

Le 2012-08-27 à 23:41, Hemant Singh (shemant) a écrit :

> My personal vote is to have the CLAT LAN win if a DAD duplicate is detected in that the CLAT LAN continues with IPv6 operations and the LAN host is denied.  However, this is new behavior above and beyond RFC 4862.  A v6ops document cannot specify new protocol behavior.   

Right.

> However, I still do not like the special-case of reserved IID because then the SP IPv6 nodes also change to special-case the new reserved IID.  So now what do we do?  

Since this is apparently your only reason for objecting to the reserved IID, which solves an otherwise unresolved issue, could you clarify what you mean by "SP IPv6 nodes also change to special-case the new reserved IID"? 
(Only CLAT nodes are concerned with using the reserved IID, and they have to be upgraded anyway.)  

RD

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 00:00:42 +0000

Remi,

-----Original Message-----
From: Rémi Després [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 6:48 PM
To: Hemant Singh (shemant)
Cc: Cameron Byrne; Lorenzo Colitti; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>Since this is apparently your only reason for objecting to the reserved IID, which solves an otherwise unresolved issue, could you clarify what you mean >by "SP IPv6 nodes also change to special-case the new reserved IID"? 

First, the IPv6 link-local address of the LAN of the CLAT is not covered by the reserved CLAT IID and the CLAT LAN is expected to generate the link-local using the EUI-64 format.  Only if there is bad hardware in the LAN segment of the CLAT do we have a duplicate link-layer address and this is a problem no one can solve with computer automata.  Manual intervention is required.
 
The reserved IID range is applicable to global IPv6 addresses.   If an IID range is reserved for CLAT use, doesn't the SP access network and its provisioning systems serving the CLATs have to make sure to not allocate IPv6 addresses from IPv6 subnet pools that match the CLAT reserved IID range? Additionally, even when a reserved IID range is used, a host in the LAN segment can still generate CGA or privacy addresses that could clash with an IPv6 address from the reserved IID range.  So what good is the reserved IID?  Please also see RFC 5453 that discourages reserved IID ranges for autonomous autoconfiguration - see section 2 of RFC 5453.

Lastly, "ND Proxy" is a workable solution.  Why not then limit the xlat document to either use DHCPv6-PD or "ND Proxy"?  After all the main focus of the xlat document is XLATE and not devise every possible solution for getting a unique /64 prefix for use by XLATE.

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 Aug 2012 12:55:38 +0900

>    the hosts were active before the CLAT was operational in the LAN

Wait... so you're saying that when the user enables tethering, he needs to
manually reset the hosts on the LAN? I think that's unreasonable, and a bad
user experience. If that's the best we can do, we should give up and remove
all text describing mention of how to share the CLAT's /64 with its clients.

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Aug 2012 09:52:20 +0200

> Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

(*)
...
> The reserved IID range is applicable to global IPv6 addresses.   If an IID range is reserved for CLAT use, doesn't the SP access network and its provisioning systems serving the CLATs have to make…

1. Please note that it isn't an IID "range" that is reserved, only an IID value

2. SP access networks do assign IIDs that comply with RFC 4291 (local scope or MAC-address based EUI-64 IIDs). Thus, they cannot assign addresses whose IIDs conflict with the CLAT-reserved IID. (This address is EUI-64 not based on a MAC-address). 
Consequently, NOTHING needs to be added in SP nodes to avoid collisions between assigned IPv6 addresses and CLAT IPv6 addresses that use the reserved IID.

3. CGA addresses and privacy addresses have u-bit = 0. Since the CLAT-reserved IID has u-bit = 1. No collision is possible.

4. Section 2 of RFC 5453 says "reserved interface identifiers MUST NOT be used for autonomous autoconfiguration or for managed address configuration". That is exactly why, without manual and wrong configuration, no host can collide with a CLAT IPv6 address that uses the reserved IID.

My sentence (*) above was an answer to your saying "I still do not like the special-case of reserved IID because then the SP IPv6 nodes also change to special-case the new reserved IID.  So now what do we do?"
Since the concern you expressed is shown to be unjustified, what can be done (and should be done IMHO) is keeping in the draft that CLAT nodes that have NAT44s MAY use the CLAT-reserved IID... and publish.

I hope you can agree with this. 
(If you find one more reason to doubt, thanks for asking for clarification before making a FUD-instigating assertion.)

Regards,
RD

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 28 Aug 2012 09:54:54 +0200 (CEST)

> also have to proxy this NS.  Thus there is no getting around the ND 

The UE can/will get its address through other means than RA. In production 
right now are devices that get their /64 by means of 3GPP signalling "out 
of band", and then just point default at the rmnet0 device.

During my testing, 2 out of 4 tested devices worked fine without seeing RA 
from the GGSN at all.

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 28 Aug 2012 10:35:11 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mikael
> Abrahamsson
> Sent: Tuesday, August 28, 2012 9:55 AM

Hmm, the 3GPP specs are making SLAAC mandatory and the device shall use
it, I cannot find a reference to what you're describing in the spec. It looks that 
the devices you have a behaving 'non-standard', but it is right the 3GPP out-of-band
signalling can provide the UE with all the necessary IP configuration. 
(IPv6 prefix, DNS resolvers, link-local IID).

> During my testing, 2 out of 4 tested devices worked fine without seeing RA

Interesting, thanks for sharing.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Aug 2012 11:36:28 +0300

On Aug 28, 2012, at 10:54 AM, Mikael Abrahamsson wrote:

> The UE can/will get its address through other means than RA. In production right now are devices that get their /64 by means of 3GPP signalling "out of band", and then just point default at the rmnet0 device.
> 
> During my testing, 2 out of 4 tested devices worked fine without seeing RA from the GGSN at all.

Relying on NAS signaling to provide the prefix is non standard.. may work for 3G but will fail in LTE.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 28 Aug 2012 11:57:44 +0300

Hemant,

> In 60 minutes (as per RFC 4389) my phone disables ND Proxy when the phone needs ND Proxy with a /64 assigned to the phone.  My phone tethering support is not available any more.  Now I have an atta…

Life is tough ;=)

> Each of the two phones in my example, by itself, complies to the xlat document and also the RFC 4389.  It is perfectly reasonable to have both phones enabled at the same time but powered on at different times.  Then 

Agree on your sentiment of the user behavior. I must be missing something here. Is 
your assumption that both mobiles and CPE's bridge would automatically also join a
mesh/wds type of setup? That would be a board assumption imho.

- Jouni

> any mis-configured tethered network can disrupt network services of one of the phones or both.  We should caution use of the ND Proxy.  Here is some proposed text to add to section 8.3.2 of the xlat document
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 28 Aug 2012 02:44:45 -0700 (PDT)

----- Original Message -----
> From: Vízdal Aleš <[email-masked]>
> To: Mikael Abrahamsson <[email-masked]>; Hemant Singh (shemant) <[email-masked]>
> Sent: Tuesday, 28 August 2012 6:35 PM
> Mikael

The shame of that approach (and it's the reason why IPv6CP in PPP doesn't do it any more), is that the option set becomes constrained to what ever the link layer signalling protocol currently supports. If they'd stuck with the IPv6 approach of using DHCPv6 over the top of the once both the link and basic IPv6 had been established, then what ever current and future options the DHCPv6 server and DHCPv6 client on the UE supported would automatically be "supported" by the link layer, without the link layer signalling specs needing to be revised, and firmware updates to the GGSN to provide the new option being deployed. The GGSN would act as a DHCPv6 relay, which makes it current and future DHCPv6 option transparent.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 14:24:43 +0000

Mikael,

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 3:55 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Mark ZZZ Smith; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>During my testing, 2 out of 4 tested devices worked fine without seeing RA 

The xlat document has referenced RFC 6459 which mandates the UE use SLACC and the RA from the SP.  See section 5.2 of RFC 6459.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 14:31:07 +0000

Jouni,

-----Original Message-----
From: jouni korhonen [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 4:58 AM
To: Hemant Singh (shemant)
Cc: Victor Kuarsingh; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>mesh/wds type of setup? That would be a board assumption imho.

I just made the case for one mis-configured tethered network that includes a bridge behind a wireless router that loops all traffic back to the CPE router who sends the traffic to the Wi-Fi link of the UE.  Now that I know how to shutdown ND Proxy on the CLAT, all I have to do is send an RA to the Wi-Fi link of the UE and the tethered service is disabled. 

A better solution is to have the UE support DHCPv6-PD. 

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 14:47:29 +0000

Lorenzo,

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Monday, August 27, 2012 11:56 PM
To: Hemant Singh (shemant)
Cc: Rémi Després; Cameron Byrne; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>Wait... so you're saying that when the user enables tethering, he needs to manually reset the hosts on the LAN? I think that's unreasonable, and a bad user experience. If that's the best we can do, >we should give up and remove all text describing mention of how to share the CLAT's /64 with its clients.

It is an interesting situation.  A Wi-Fi  host in the LAN segment is active with only the link-local address because the host hasn't seen any RA.   Later, the CLAT UE powers up and gets operational and issues an RA in the LAN segment of the CLAT.  The host receives the RA and acquires a global IPv6 address using SLAAC or DHCPv6 and issues a NS(DAD) for the global IPv6 address.   No DAD operation is invoked for the link-local address which could be duplicate with the CLAT LAN interface link-local.   That is why a reset of the tethered host makes sense so that the CLAT sees both the link-local and the global IPv6 address of the host.

Hemant

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 28 Aug 2012 16:58:31 +0200

Hemant,

> Sent: Tuesday, August 28, 2012 4:31 PM
> To: jouni korhonen
> Cc: [email-masked]
> I just made the case for one mis-configured tethered network that includes a bridge
> behind a wireless router that loops all traffic back to the CPE router who sends the
> traffic to the Wi-Fi link of the UE.  Now that I know how to shutdown ND Proxy on the
> CLAT, all I have to do is send an RA to the Wi-Fi link of the UE and the tethered
> service is disabled.
> 

the UE wouldn't be much of an issue, but the network support for IPv6 and subsequently for PD ...
I am sorry, but tethering using /64 will be required and will become a reality in mobile.

Ales

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 28 Aug 2012 17:00:33 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of jouni
> korhonen
> Sent: Tuesday, August 28, 2012 10:36 AM
> To: Mikael Abrahamsson
> Cc: [email-masked]
> >> Thanks for the details in your other email.  The UE will still need to proxy the RA
> from the service provider to the wlan0 segment of the UE. Further an NS arrives at
> cell0 from the service provider.  The UE will also have to proxy this NS.  Thus there is
> no getting around the ND Proxy.
> >
> > The UE can/will get its address through other means than RA. In production right
> now are devices that get their /64 by means of 3GPP signalling "out of band", and then
> just point default at the rmnet0 device.
> >

It may work in 3G, but it clearly violates the 3GPP TS29.061 v10.6.0, section 11.2.1.3.2 where it says:

5x.The Attach Accept message will be sent along to the UE without the IPv6 prefix. The UE shall ignore the IPv6 prefix if it receives one in the message.

Ales

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Aug 2012 17:04:06 +0200

Le 2012-08-28 à 16:47, Hemant Singh (shemant) a écrit :

> It is an interesting situation.  A Wi-Fi  host in the LAN segment is active with only the link-local address because the host hasn’t seen any RA.   Later, the CLAT UE powers up and gets operational and issues an RA in the LAN segment of the CLAT.  The host receives the RA and acquires a global IPv6 address using SLAAC or DHCPv6 and issues a NS(DAD) for the global IPv6 address.   

> No DAD operation is invoked for the link-local address which could be duplicate with the CLAT LAN

The CLAT-node downstream address is either EUI-64, which shouldn't conflict with that of any host on the LAN, or is local scope, in which case it should be subject to DAD before being confirmed.

In any case, none of thee addresses can conflict with the CLAT upstream address if this address has the CLAT-reserved IID.

RD

> interface link-local.   That is why a reset of the tethered host makes sense so that the CLAT sees both the link-local and the global IPv6 address of the host.
>  
> Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 15:11:38 +0000

Vizdal,

-----Original Message-----
From: Vízdal Aleš [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 10:59 AM
To: Hemant Singh (shemant); jouni korhonen
Cc: [email-masked]
Subject: RE: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>I am sorry, but tethering using /64 will be required and will become a reality in mobile.

No apologies needed.  Go ahead and use ND Proxy as I and Cameron (remove any reference to RFC 4389) have proposed for text in a re-worked section 8.3.2 which was:

"The CLAT uses an ND Proxy to share the single /64 prefix between the LAN and WAN segments."

In another email I had proposed one other sentence to note a pitfall with use of ND Proxy.  Maybe we can add that text too and the new text looks as follows:

"The CLAT uses an ND Proxy to share the single /64 prefix between the LAN and WAN segments.  Note any loop in the CLAT tethered network may cause the ND Proxy on the UE to be disabled."

Regards,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 15:38:12 +0000

Remi,

From: Rémi Després [mailto:[email-masked]]
Sent: Tuesday, August 28, 2012 11:04 AM
To: Hemant Singh (shemant)
Cc: Lorenzo Colitti; Cameron Byrne; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>The CLAT-node downstream address is either EUI-64, which shouldn't conflict with that of any host on the LAN, or is local scope, in which case it should be subject to DAD before being >confirmed.

This thread has already discussed that even with EUI-64, due to bad hardware, even EUI-64 compliant link-local addresses can clash.  Since the host is up and running with a link-local before the CLAT UE is up, the host does not perform DAD for the link-local.

Hemant

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Aug 2012 17:46:57 +0200

Le 2012-08-28 à 17:38, Hemant Singh (shemant) a écrit :

> This thread has already discussed that even with EUI-64, due to bad hardware, even EUI-64 compliant link-local addresses can clash. 

Sure, two EUI-64 with the same embedded MAC address can clash, but this has nothing to do with 464XLAT.
Not sure what you are trying to explain here. (The point of the CLAT-reserved IID is to prevent any possible clash with LAN hosts having good hardware and software.)

RD

> Since the host is up and running with a link-local before the CLAT UE is up, the host does not perform DAD for the link-local.
>  
> Hemant
>

---

From: GangChen <[email-masked]>
Date: Wed, 29 Aug 2012 00:26:30 +0800

Hemant,

> No apologies needed.  Go ahead and use ND Proxy as I and Cameron (remove any
> reference to RFC 4389) have proposed for text in a re-worked section 8.3.2
> which was:
>
> In another email I had proposed one other sentence to note a pitfall with
> use of ND Proxy.  Maybe we can add that text too and the new text looks as
> follows:
>
> "The CLAT uses an ND Proxy to share the single /64 prefix between the LAN
> and WAN segments.  Note any loop in the CLAT tethered network may cause the
> ND Proxy on the UE to be disabled."

Since the reference of RFC4389 is likely removed, I'm not sure why we
should note the loop issue here.

BRs

Gang

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 16:43:02 +0000

Gang,

-----Original Message-----
From: GangChen [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 12:27 PM
To: Hemant Singh (shemant)
Cc: Vízdal Aleš; jouni korhonen; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>should note the loop issue here.

Ok, great point from you.  We can remove the loop issue then.  

Thanks,

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 28 Aug 2012 19:31:39 +0000

Remi,

-----Original Message-----
From: Rémi Després [mailto:[email-masked]] 
Sent: Tuesday, August 28, 2012 3:52 AM
To: Hemant Singh (shemant)
Cc: Cameron Byrne; Lorenzo Colitti; [email-masked]
Subject: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>1. Please note that it isn't an IID "range" that is reserved, only an IID value

The IANA section of the xlat document lists two IID values and that is what I was referring to as "range" though not completely correctly. 

>2. SP access networks do assign IIDs that comply with RFC 4291 (local scope or MAC-address based EUI-64 IIDs). 

That is the missing link between us.  I thought, why not global scope?  If global scope, then the SP has to check the reserved IID values before configuring the network to not use an IPv6 address with an IID that is a reserved IID.   Thanks for the information on CGA and Privacy addresses that are not global and thus I agree with you, no clash is possible with CGA/Privacy address vs. a CLAT IID with "u" bit as 1.

Another question.  Why does the xlat document need another solution for getting a /64 to use by CLAT for XLATE when an ND Proxy solution exists?

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Aug 2012 09:53:29 +0900

On Tue, Aug 28, 2012 at 11:47 PM, Hemant Singh (shemant)
<[email-masked]>wrote:

>  It is an interesting situation.  A Wi-Fi  host in the LAN segment is
> active with only the link-local address because the host hasn’t seen any
> RA.   Later, the CLAT UE powers up and gets operational and issues an RA in
> the LAN segment of the CLAT.  The host receives the RA and acquires a
> global IPv6 address using SLAAC or DHCPv6 and issues a NS(DAD) for the
> global IPv6 address.
>

Which fails if it picked the same IID as the CLAT. Which is working as
intended.

> No DAD operation is invoked for the link-local address which could be
> duplicate with the CLAT LAN interface link-local.
>

Incorrect. Per RFC 4862 section 5.4, DAD MUST be performed on all unicast
addresses, including link-local addresses.

>    That is why a reset of the tethered host makes sense so that the CLAT
> sees both the link-local and the global IPv6 address of the host.
>

The reason you cite above is invalid. Do you have another reason to say
that the host should be reset?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Aug 2012 09:57:29 +0900

> addresses, including link-local addresses.

Oh, wait - I see what you mean. You're saying that the host *does* perform
DAD for its link-local address, but it does that when the CLAT is not on
the link yet. This is still not an issue, for two reasons:

1. If the CLAT is the tethering router, then there is no link until the
CLAT comes up, so what you describe cannot happen.
2. The CLAT does not use that IID for its link-local address anyway - it
forms the link-local address from its wlan0 EUI-64 IID.

So again, I see no need to reset the host.

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Aug 2012 08:48:04 +0200

> The IANA section of the xlat document lists two IID values and that is what I was referring to as "range" though not completely correctly.

Two values in -07, yes, but:
- IANA being required to keep only one
- as suggested in item (1) of www.ietf.org/mail-archive/web/v6ops/current/msg13856.html, the choice can be made by IETF in favor of 02-00-5E-10-00-00-00-00 (value used in the Appendix) before its request to IANA.

> That is the missing link between us.  I thought, why not global scope?  If global scope, then the SP has to check the reserved IID values before configuring the network to not use an IPv6 address w…

There is no collision risk between a host global-scope IID and the CLAT-reserved IID because:
- host global-scope IID are EUI-64 based, containing the manufacturer unique identifier (OUI) and manufacturer-assigned extension identifier
- the CLAT-resreved IID contains the IANA OUI which differs from all manufacturer OUIs (as already used in for ISATAP (tools.ietf.org/html/rfc5214#section-6.1). 

> Another question.  Why does the xlat document need another solution for getting a /64 to use by CLAT for XLATE when an ND Proxy solution exists?

Use of the CLAT-resreved IID is independent from how the IPv6 prefix is obtained. 
BTW, note that it can usefully be used also with /x sorter than /64: it eliminates the need to reserve for 464XLAT a /64 derived from this /x. 

Again, I hope you finally acknowledge that your objections to the CLAT-resreved IID have all been resolved. (If not, your additional questions remain welcome.)

Regards,
RD

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 Aug 2012 16:10:38 +0900

On Wed, Aug 29, 2012 at 3:48 PM, Rémi Després <[email-masked]>wrote:

> Again, I hope you finally acknowledge that your objections to the
> CLAT-resreved IID have all been resolved. (If not, your additional
> questions remain welcome.
>

Remi,

can we please have the discussion on the IID on another thread and not on
this one? This thread was started to discuss the model where the CLAT
shares a single /64 with its clients, which is a separate problem.

Thanks,
Lorenzo

---

From: Rémi Després <[email-masked]>
Date: Wed, 29 Aug 2012 09:33:04 +0200

Le 2012-08-29 à 09:10, Lorenzo Colitti a écrit :

> On Wed, Aug 29, 2012 at 3:48 PM, Rémi Després <[email-masked]> wrote:
> Again, I hope you finally acknowledge that your objections to the CLAT-resreved IID have all been resolved. (If not, your additional questions remain welcome.
> 
> Remi,
> 
> can we please have the discussion on the IID on another thread and not on this one? This thread was started to discuss the model where the CLAT shares a single /64 with its clients, which is a separate problem.

Why not?
But I answer here to objections made on this list.
If there is no objection, there is no answer.

Cheers,
RD

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 29 Aug 2012 12:03:28 +0000

Lorenzo,

Sent: Tuesday, August 28, 2012 8:57 PM

>Oh, wait - I see what you mean. You're saying that the host *does* perform DAD for its link-local address, but it does that when the CLAT is not on the >link yet. This is still not an issue, for two reasons:

>1. If the CLAT is the tethering router, then there is no link until the CLAT comes up, so what you describe cannot happen.

Agree.  However, I am in my home and my wi-fi IPv6 node can pick up any wireless signal from the home or the neighborhood and get active on the wi-fi link with a link-local address but does not see any RA.   Now when the CLAT wi-fi link is  up, the IPv6 node has to be reset to move to the new wi-fi link.  Anyway, such a reset is obvious.  Thus the following text goes away from my proposal.

"Additionally, it is expected the hosts in the LAN segment of the CLAT are reset for new IPv6 address acquisition if the hosts were active before the CLAT was operational in the LAN segment."

New text for section 8.3.2 is now:

   
   and WAN segments.  

>2. The CLAT does not use that IID for its link-local address anyway - it forms the link-local address from its wlan0 EUI-64 IID.

Right.  I too, said the same thing the other day.  See below where I said bad hardware can cause a duplicate for the link-local and that is why DAD for the link-local is needed.

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

>So again, I see no need to reset the host.

Agree.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 29 Aug 2012 17:33:50 +0000

Cameron,

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]] 
Sent: Saturday, August 25, 2012 4:41 PM
To: Ray Hunter
Cc: Hemant Singh (shemant); [email-masked]; Lorenzo Colitti
Subject: Re: Re: [v6ops] single /64, ND Proxy, and draft-ietf-v6ops-464xlat-07.txt

>Else if EUI-64 reserved address available, do that.

Example 2 in Appendix A only gives an example using EUI-64 reserved IID.  The more interesting example to show would be for how the ND Proxy works.  I don't mean to ask how an "ND Proxy" works, but the example for what the document proposes the ND Proxy case should do with a single /64 and generate a source IPv6 address from to send packets to the PLAT?  I have two choices below shown from RFC 6052 the ND Proxy example could use.  The suffix is all zeroes.

    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |64|     prefix                    | u |   v4(32)      | suffix    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |96|     prefix                                    |    v4(32)     |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Thanks,

Hemant

---

From: Rémi Després <[email-masked]>
Date: Thu, 30 Aug 2012 08:35:21 +0200

Hi, all,

2012-08-29 à 19:33, Hemant Singh (shemant) :
...
> Example 2 in Appendix A only gives an example using EUI-64 reserved IID.  The more interesting example to show would be for how the ND Proxy works.  I don't mean to ask how an "ND Proxy" works, but…

Note that:
- The external NAT44 address can be the unspecified IPv4 address 0.0.0.0. (It does make sense since this external address is never used in IPv4, and can take any value). 
- the /96 can be the CLAT-node /64 followed by 200:5e10::/32 (the EUI-64 IANA /32)

Then, the CLAT IPv6 address DOES CONTAIN the CLAT-resreved EUI-64 IID 02-00-5E-10-00-00-00-00.
There is therefore NO CONFLICT between using ND proxy an using the EUI-64 resreved IID.

(As already documented, advantage of the reserved IID is that the CLAT IPv6 address cannot conflict with that of any RFC4291-compliant host. Consequently, if the CLAT is activated AFTER hosts have been assigned their IPv6 addresses, neither the CLAT nor any host needs to change its IPv6 address.)

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 31 Aug 2012 16:45:36 +0200

Hi, all,

A interesting fact is that benefit of using an IANA-resreved EUI-64 IID for the NAT44 case can be extended to the non-NAT44 case. Thus:
- ND proxy is no longer needed to prevent native IPv6 addresses of client hosts to conflict with IPv4-embedded CLAT addresses.
- This prevention applies even if hosts obtain their addresses before CLAT activation, and aren't reset. 

For this, it is sufficient that, instead of just reserving IID 200:5e10::/64 for one address, reservation is also made for an exclusive /40 IID prefix. 

More precisely, having CLATs to use 10../8 private addresses on their LAN side, and reserving IID prefix 200:5e10:a000::/40, the end result is: 
- IPv4-embedded IPv6 addresses of CLATs are <CLAT_/64>:200:5e10:<host_v4p_address>, where CLAT_64 is any IPv6 prefix in the space assigned to the CLAT node.
- No ND proxy is needed to prevent hosts to conflict with this address.
- Conflicts are avoided even for host that get their IPv6 addresses before CLAT activation.
- No need to assign a 464XLAT specific prefix, and /64 assignments are supported. 

Sorry for not having seen this before (probably because focusing exclusively on the NAT44 case) but, following the discussion on ND proxy, this seems to me a significant simplification of CLAT design and operation.

If this isn't clear enough, please don't hesitate to ask for clarification.

Regards,
RD