Subject: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt

From: [email-masked]
Date: Fri, 17 May 2013 11:54:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN
	Author(s)       : Cameron Byrne
                          Dan Drown
                          Ales Vizdal
	Filename        : draft-ietf-v6ops-64share-07.txt
	Pages           : 8
	Date            : 2013-05-17

Abstract:
   This document describes three methods for extending an IPv6 /64
   prefix from a User Equipment 3GPP radio interface to a LAN.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-64share

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-64share-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-64share-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Smith <[email-masked]>
Date: Thu, 23 May 2013 14:08:36 -0700 (PDT)

Hi,

Suggested changes:

1. Introduction

"... for delegating IPv6 prefixes to a LAN."

to 

""... for delegating IPv6 prefixes to a single LAN interface."

Generally I think this intro text should make it a bit clearer that these methods are only extending the /64 to a single LAN interface.

3.1 Scenario 1: No Global Address on the UE

"traffic destine"

- missing "d" on destined.

"the UE (e.g. DNS caching that requires global connectivity) and prevent proper Path MTU Discovery [RFC1981] to occur on the UE providing an IPv6 router function."

Regarding breaking PMTUD, I wonder if it might be worth requiring that the MTU of the LAN interface is made the same as that of the 3GPP interface, and if it isn't the default for the LAN interface (i.e., 1500 for ethernet), then the LAN interface RAs have the MTU option set to the size of the 3GPP interface. I think that would prevent the UE needing to participate in PMTUD.

"The UE copies the prefix 2001:db8:ac10:f002::/64 from the 3GPP interface to the LAN interface,"

I think it would be clearer if this text specified that this copying of the /64 prefix was indicating the prefix was on-link, by adding the prefix to the Prefix List, as per RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes"

3.2 Scenario 2: Global Address Only Assigned to LAN

"The movement of the IPv6 prefix from the 3GPP radio interface to the LAN interface may result in long-lived data connections being terminated during the transition from a host-only mode to router-and-host mode."

I'd suggest adding something like:

"Connections which are likely to be effected are ones that have been specifically bound to the 3GPP radio interface."

3.3 Scenario 3: A Single Global Address Assigned to 3GPP Radio and LAN Interface

"This method also creates complications for ensuring uniqueness for Privacy Extensions [RFC4941].  Privacy Extensions should be disabled on the 3GPP radio interface while this method is enabled."

I think it would be better to advise that when privacy extensions are in use, a single privacy address is generated, and then used as the anycast address on both interfaces, and the preferred and valid lifetimes are synchronised, such that the anycast addresses on both interfaces expires at the exact same moment.

Hmm, actually, there might be another more broader issue to consider (broader than this specific scenario), regarding preferred and valid lifetimes of the /64. What preferred and valid lifetimes are supplied in the RAs by the 3G network, and should they be copied to the LAN interface RAs? Another issue related to this is the synchronised aging of the prefix on the 3GPP and LAN interfaces. In the case of DHCPv6 PD, the preferred and valid lifetimes announced in the LAN RAs are to be synchronised with the aging of the DHCPv6-PD prefix, so that when the PD prefix expires, the addresses on the hosts on the LAN expire at the same time.

HTH,
Mark.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 May 2013 20:45:05 +0200

Le 23/05/2013 23:08, Mark Smith a écrit :
> Generally I think this intro text should make it a bit clearer that
> these methods are only extending the /64 to a single LAN interface.

Yes.

Moreover, it should be clear that this extension only works with only
one level of extension (one cant have 64share-64share-... indefinitely,
not even twice).

> - missing "d" on destined.

Better say 'targeted' or 'addressed to'.  Exchanged with peers
addressable by.

> "the UE (e.g. DNS caching that requires global connectivity) and
> prevent proper Path MTU Discovery [RFC1981] to occur on the UE
> providing an IPv6 router function."
>
>
> Regarding breaking PMTUD, I wonder if it might be worth requiring
> that the MTU of the LAN interface is made the same as that of the
> 3GPP interface, and if it isn't the default for the LAN interface
> (i.e., 1500 for ethernet), then the LAN interface RAs have the MTU
> option set to the size of the 3GPP interface. I think that would
> prevent the UE needing to participate in PMTUD.
>
>
> I think it would be clearer if this text specified that this copying
> of the /64 prefix was indicating the prefix was on-link, by adding
> the prefix to the Prefix List, as per RFC5942, "IPv6 Subnet Model:
> The Relationship between Links and Subnet Prefixes"
>
>
> "The movement of the IPv6 prefix from the 3GPP radio interface to
> the LAN interface may result in long-lived data connections being
> terminated during the transition from a host-only mode to
> router-and-host mode."
>
>
> "Connections which are likely to be effected are ones that have been
> specifically bound to the 3GPP radio interface."

One other way to think about this is the follozing:

If for any reason the 3GPP UE changes its IPv6 address (disconnect and
reconnect, because of short transitions, or other error) then it is
highly likely that the IPv6 address changes, and its first 64 bits may
change as well.  At that point, it should be clear than any other
address on the LAN that is formed by prefixing with these 64bits, as
well as the address itself attached on UE's LAN interface, will change.
  This will certainly incur disruption in communication.

This could go as far as to say that the 64share method works only for
static UEs.  It sounds negative, I know, but the reliability of this
should be acknowledged.

Yours,

Alex

> "This method also creates complications for ensuring uniqueness for
> Privacy Extensions [RFC4941].  Privacy Extensions should be disabled
> on the 3GPP radio interface while this method is enabled."
>
>
> I think it would be better to advise that when privacy extensions
> are in use, a single privacy address is generated, and then used as
> the anycast address on both interfaces, and the preferred and valid
> lifetimes are synchronised, such that the anycast addresses on both
> interfaces expires at the exact same moment.
>
> Hmm, actually, there might be another more broader issue to consider
> (broader than this specific scenario), regarding preferred and valid
> lifetimes of the /64. What preferred and valid lifetimes are
> supplied in the RAs by the 3G network, and should they be copied to
> the LAN interface RAs? Another issue related to this is the
> synchronised aging of the prefix on the 3GPP and LAN interfaces. In
> the case of DHCPv6 PD, the preferred and valid lifetimes announced in
> the LAN RAs are to be synchronised with the aging of the DHCPv6-PD
> prefix, so that when the PD prefix expires, the addresses on the
> hosts on the LAN expire at the same time.
>
>
> HTH, Mark. _______________________________________________ v6ops
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Vízdal Aleš <[email-masked]>
Date: Sat, 25 May 2013 01:18:30 +0200

Hi Alex,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexandru Petrescu
> Sent: Friday, May 24, 2013 8:45 PM
> To: [email-masked]
> Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-64share-07.txt

> Better say 'targeted' or 'addressed to'.  Exchanged with peers addressable by.

As a packet has its destination it is 'destined to' an address ... Let's keep it as is to
avoid confusion.

> > "The movement of the IPv6 prefix from the 3GPP radio interface to the
> > LAN interface may result in long-lived data connections being
> If for any reason the 3GPP UE changes its IPv6 address (disconnect and reconnect,
> because of short transitions, or other error) then it is highly likely that the IPv6
> address changes, and its first 64 bits may change as well.  At that point, it should be
> clear than any other address on the LAN that is formed by prefixing with these 64bits,
> as well as the address itself attached on UE's LAN interface, will change.
> This could go as far as to say that the 64share method works only for static UEs.  It
> sounds negative, I know, but the reliability of this should be acknowledged.

Section 3.0 General Behavior for All Scenarios clearly states: 

"If the 3GPP interface goes down or changes the IPv6 prefix, that state should be reflected 
in the LAN IPv6 configuration."

So the solution is not limited to UEs with a static IPv6 prefix. Any changes on the 3GPP
link shall be propagated to the LAN. (the old IPv6 prefix to be deprecated and the new one 
to be advertised to the LAN)

> Alex

Cheers,
Ales

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 May 2013 11:42:26 -0700

>> these methods are only extending the /64 to a single LAN interface.

How can that work in the real world?

For example, with my iPhone 5 running on VZW, I seem to get the same /64
over the WiFi (mobile hotspot), the Cellular_PDP0 interface (the actual
cellular interface), BlueTooth (mobile hotspot), and USB (mobile hotspot).

From my perspective that's 3 LAN interfaces and a WAN interface sharing the
same /64.

> one level of extension (one cant have 64share-64share-... indefinitely,

This part makes sense to me.

But bridging the 64share prefix across multiple LAN interfaces on the
device (or even extending it via bridges on the LAN side) does not seem
to be a problem IMHO.

> static UEs.  It sounds negative, I know, but the reliability of this

I wouldn't go quite that far. Acknowledging the limitations makes sense to me.
Expanding upon those limitations to say that nobody can make a decision to
accept them and deploy anyway is not correct, IMHO.

Owen

---

From: "cb.list6" <[email-masked]>
Date: Sat, 25 May 2013 13:26:36 -0700

> From my perspective that's 3 LAN interfaces and a WAN interface sharing
the

At the same time?

In any event, that implementation you mentioned is not publicly documented.
The folks at Apple and Verizon are welcome to share their wisdom on this
topic.

In any event, the work of this draft is to  use the open ietf process to
get folks on the same page so the wheel does not get reinvented several
times in a vacume.

CB

> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Sat, 25 May 2013 19:08:32 -0700 (PDT)

----- Original Message -----
> From: Owen DeLong <[email-masked]>
> To: Alexandru Petrescu <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, 26 May 2013 4:42 AM

I think the "LAN interface" in this draft is from the perspective of IPv6, and in your scenario, all those interfaces, if they're all using the same /64, are a single LAN (perhaps they're bridged or some similar trick below IPv6).

However, maybe it would be better to adopt the IPv6 RFC2461 "Link" terminology i.e. this draft is extending the use of the 3GPP /64 prefix onto another link available on the UE, such as a Wifi interface etc.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 May 2013 22:34:44 -0700

> However, maybe it would be better to adopt the IPv6 RFC2461 "Link" terminology i.e. this draft is extending the use of the 3GPP /64 prefix onto another link available on the UE, such as a Wifi inte…

Agreed... If the terminology were changed form interface (which has a vague meaning in IPv6) to link (which is more specific and more appropriate), then I would agree.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 25 May 2013 22:33:19 -0700

> > From my perspective that's 3 LAN interfaces and a WAN interface sharing the
Yes..

> In any event, that implementation you mentioned is not publicly documented. The folks at Apple and Verizon are welcome to share their wisdom on this topic.
> 
Agreed. I wish they would/hope they do. However, bottom line, it's running code today.
> In any event, the work of this draft is to  use the open ietf process to get folks on the same page so the wheel does not get reinvented several times in a vacume.
> 

Agreed. However, that doesn't mean we need to invent an inferior wheel.

Owen

---

From: "cb.list6" <[email-masked]>
Date: Sun, 26 May 2013 15:27:22 -0700

On Sat, May 25, 2013 at 10:33 PM, Owen DeLong <[email-masked]> wrote:
> In any event, the work of this draft is to  use the open ietf process to get
> folks on the same page so the wheel does not get reinvented several times in
> a vacume.
>
>

well, we ship what gets rough consensus, not what is "best" for some
value of "best"

Back in the archives, we scoped the scenario to be one routed
down-link due to folks concerns about loops that would result from
having multiple interfaces up with the same prefix.

i think the discussion was somewhere around here and how NDproxy was
not acceptable

http://www.ietf.org/mail-archive/web/v6ops/current/msg13954.html and
http://www.ietf.org/mail-archive/web/v6ops/current/msg15020.html

CB

---

From: Owen DeLong <[email-masked]>
Date: Mon, 27 May 2013 10:02:02 -0700

> well, we ship what gets rough consensus, not what is "best" for some

Unless there is a reason to do so, I cannot imagine that rational individuals would come to consensus on an inferior choice.

> having multiple interfaces up with the same prefix.

Ah, but as was described earlier, interface != link and if we simply move to the term link, the problem is resolved. The use of the term interface is what is problematic here. Multiple interfaces which are bridged together at layer 2 constitute a single link from an IPv6 perspective.

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

Which only applies in the case of multiple links with the same prefix, not multiple interfaces within the same link.

Owen

---

From: "cb.list6" <[email-masked]>
Date: Mon, 27 May 2013 10:35:00 -0700

On May 27, 2013 10:04 AM, "Owen DeLong" <[email-masked]> wrote:
> Unless there is a reason to do so, I cannot imagine that rational
individuals would come to consensus on an inferior choice.
> Ah, but as was described earlier, interface != link and if we simply move
to the term link, the problem is resolved. The use of the term interface is
what is problematic here. Multiple interfaces which are bridged together at
layer 2 constitute a single link from an IPv6 perspective.
> Which only applies in the case of multiple links with the same prefix,
not multiple interfaces within the same link.
> Owen

Ok, so in the draft we change interface to link and the magic of how loops
and so on are prevented is out of scope since it is in the domain of "link"?

I am fine with that.

Is that "one word" change that is  needed to close this particular topic?

CB

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 10:39:27 +0900

I'm not sure, but I think the fundamental problem is the same as it has
always been: "if you ND proxy a downstream interface to an upstream
interface, you're gonna have a bad time" - because that can create loops.

However, I think that doing proxy ND between multiple downstream subnets
would work fine.

As Owen says, we should not document an inferior wheel. So we should not
finalize this document if we do not know the answer to this question. Does
anyone know the answer?

On Tue, May 28, 2013 at 2:35 AM, cb.list6 <[email-masked]> wrote:

> > Ah, but as was described earlier, interface != link and if we simply
> move to the term link, the problem is resolved. The use of the term
> interface is what is problematic here. Multiple interfaces which are
> bridged together at layer 2 constitute a single link from an IPv6
> perspective.
> >

---

From: "cb.list6" <[email-masked]>
Date: Mon, 27 May 2013 18:57:13 -0700

> However, I think that doing proxy ND between multiple downstream subnets

Right, and previous discussion on this topic says their is no way to
prevent it from happening without some heavy-lifting to change ND or
otherwise accepting risks that have been deemed unacceptable

> finalize this document if we do not know the answer to this question. Does

The previous answer was to scope the wheel to be one link / interface.

I would like to not let perfect be the enemy of good, and...  also
call out that there are shipping implementations that are undocumented
because the need arose before the IETF was willing to discuss it.  It
reminds me of how the IETF denied the existence of NAT and therefore
there was a  cornucopia of implementation variations.

This draft introduces a handful of scenarios that have been reviewed
by the IETF, it is "only" informational, and my goal is to limit that
cornucopia to a safe set of simple vetted solutions

Alternatively, we can put our heads back in the sand and tell everyone
DHCP-PD is the only way forward and watch that be ignored  while
off-the-cuff implementations roll out (this is, in fact, the current
state with Apple (iPhone), ZTE (4G router), and Samsung (Android
phones) all shipping prefix sharing implementations.)

CB

>> > interface is what is problematic here. Multiple interfaces which are bridged
>> > together at layer 2 constitute a single link from an IPv6 perspective.
>> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 11:16:44 +0900

>         Filename        : draft-ietf-v6ops-64share-07.txt

Substantive comments:

1. The introduction needlessly limits the scope of this document to 3GPP
devices. This scheme works anywhere the uplink is a point-to-point
interface. 3GPP devices happen to fall into that category, and the fact
that 3GPP currently only a /64 is a use case for this document, but it's
not the only one. So I think this scheme should be documented in the more
general case and the 3GPP use case should be documented as a use case.

2. I think scenario #1 should be removed. An IPv6 router without a global
scope IPv6 address? First of all, why? There are plenty of addresses in the
/64. Second, how is the router going to fulfill the router requirements
that require it, for example, to send ICMP error messages? We can't say
that it's OK for a router not to be able to support PMTUd, send
unreachables, support traceroute, etc.  for transit traffic. Third, this
mode doesn't even simplify implementation, because the sharing device has
to do autoconf on the uplink anyway to get the prefix to share. Fourth,
disabling autoconf once sharing is enabled means that this method will not
work on any network where the upstream prefix can change. Why was this mode
included?

3. Scenarios #2 and #3 are underspecified. For example, what does the RA on
the LAN look like? Is it a copy of the RA from the WAN? Presumably not,
since we'd want to include the link-layer address of the router in it. Does
the sharing device decrement the TTL? And so on. Instead of putting these
as details in the scenarios, they should probably be put in a more general
requirements section whose job it is to explain what the sharing device
must do in order for the IPv6 protocol to work correctly when sharing a
/64. The scenarios would then become examples of ways you can do this.

4. Some of the language is inappropriately vague. For example, what does
"defends its LAN IPv6 address with DAD" mean?

5. It's not OK to say that privacy extensions should be disabled. I think
the document should say that if the sharing device has privacy addresses,
it should maintain them, and if it does maintain them, it must support DAD
for those addresses on its downstream interface(s).

6. The document should say that said neighbor advertisements are proxy
neighbour advertisements per RFC 4861 section 7.2.8. Note that this is
different from ND proxy (RFC 4389), which is experimental.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 11:22:37 +0900

> otherwise accepting risks that have been deemed unacceptable

Actually, I don't believe the question of how this would work with multiple
downstream interfaces has been explored before in this group.

> The previous answer was to scope the wheel to be one link / interface.

Is there a solid technical reason for doing so? Have we even discussed if
this is possible or not, and whether it would work?

> phones) all shipping prefix sharing implementations.)

I'm not saying that we should not publish this document. I am saying that
we should do the due diligence to inform implementers of how to do this
properly, so that we don't end up with broken (e.g., no global address on
the sharing device? How are you going to connect to it, via link-local?) or
suboptimal (e.g., only one interface) implementations.

This is the IETF. We should not simply describe the implementations that
are out there, we should do the due diligence of thinking through how
things should work, and publish a document accordingly. This is useful even
if the the current implementers know all these things, and the current
implementations do everything right, because it ensures that future
implementations behave in a sane way as well.

---

From: Mark Smith <[email-masked]>
Date: Mon, 27 May 2013 20:45:03 -0700 (PDT)

Hi,

>________________________________
> From: Lorenzo Colitti <[email-masked]>
>To: cb.list6 <[email-masked]>; "[email-masked]" <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]> 
>Sent: Tuesday, 28 May 2013 12:16 PM
>Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-64share-07.txt
> 
>
>
>1. The introduction needlessly limits the scope of this document to 3GPP devices. This scheme works anywhere the uplink is a point-to-point interface. 3GPP devices happen to fall into that category, and the fact that 3GPP currently only a /64 is a use case for this document, but it's not the only one. So I think this scheme should be documented in the more general case and the 3GPP use case should be documented as a use case.
>

I was sort of hoping nobody would open that can of worms, as the same thing occurred to me previously. I fear that doing this would provide an excuse to some ISPs not to give out more than a single /64 if these methods are more generally adopted, contrary to the advice in RFC3177/6177. I think clearly presenting it as a work around to the limitations of the 3GPP architecture revision mentioned would be better.

<snip>

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2013 09:59:32 +0200

> Agreed. However, that doesn't mean we need to invent an inferior wheel.

haven't we invented the wheel, aka multilink subnet routing (also see RFC4903) and the inferior wheel,
RFC4389 already?

what does this document add?

cheers,
Ole

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 28 May 2013 11:41:36 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole
> Troan
> Sent: Tuesday, May 28, 2013 10:00 AM
> To: Owen DeLong
> Cc: IPv6 Ops WG
> >> In any event, the work of this draft is to  use the open ietf process to get folks on
> the same page so the wheel does not get reinvented several times in a vacume.
> >>
> >

It describes how to overcome the limitations of the 3GPP architecture until the DHCP-PD will be available.
So it adds (provides) a solution to this 3GPP specific issue.

Cheers,
Ales

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2013 11:47:11 +0200

Vizdal,

> So it adds (provides) a solution to this 3GPP specific issue.

how is that different from the RA proxy?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 20:05:50 +0900

> how is that different from the RA proxy?

Define "RA proxy"?

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2013 13:22:11 +0200

Lorenzo,

> how is that different from the RA proxy?

http://tools.ietf.org/html/rfc4389#appendix-A

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 28 May 2013 23:30:20 +0900

> how is that different from the RA proxy?

Not much, but it's more detailed. For example, it document notes that care
must be taken to avoid breaking DAD. It's also its own informational
document rather than an appendix in a different experimental RFC.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 May 2013 16:34:36 +0200

Le 28/05/2013 16:30, Lorenzo Colitti a écrit :
> On Tue, May 28, 2013 at 6:47 PM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      > It describes how to overcome the limitations of the 3GPP
>     architecture until the DHCP-PD will be available.
> Not much, but it's more detailed. For example, it document notes that
> care must be taken to avoid breaking DAD. It's also its own
> informational document rather than an appendix in a different
> experimental RFC.

I would like this to be no proxy at all.  Actually our implementation 
(which is actually simply configuration) does not do any form of proxying.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 May 2013 17:11:26 +0200

Lorenzo,

I have some viewpoints about this, which I hope reasonable.

Le 28/05/2013 04:16, Lorenzo Colitti a écrit :
> On Sat, May 18, 2013 at 3:54 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Title           : Extending an IPv6 /64 Prefix from a 3GPP Mobile
> Interface to a LAN Author(s)       : Cameron Byrne Dan Drown Ales
> Vizdal Filename        : draft-ietf-v6ops-64share-07.txt
>
>
> Substantive comments:
>
> 1. The introduction needlessly limits the scope of this document to
> 3GPP devices. This scheme works anywhere the uplink is a
> point-to-point interface. 3GPP devices happen to fall into that
> category, and the fact that 3GPP currently only a /64 is a use case
> for this document, but it's not the only one. So I think this scheme
> should be documented in the more general case and the 3GPP use case
> should be documented as a use case.
>
> 2. I think scenario #1 should be removed.

No, it works.

> An IPv6 router without a global scope IPv6 address?

YEs.  There are many cases where an IPv6 router could do only with its
link-local address.

> First of all, why?

Because, in this particular case, if it removes its globally-scoped IPv6
address then somebody else in the LAN could use it.  This avoids all the
proxy and DAD worries.

> There are plenty of addresses in the /64.

YEs, there are.  But SLAAC on Ethernet requires all be in one subnet,
and not route between one and the other of same /64.

> Second, how is the router going to fulfill the router requirements
> that require it,

I am not sure how strong these requirements are and whether they can be
modified.  Besides, this link-local address only (not global address)
router behaviour could be INFORMATIONAL, for this particular case,
rather than seeing the behaviour largely deployed but not documented at all.

> for example, to send ICMP error messages?

Well, the many of the events which would provoke these ICMP error
messages needing global-scoped instead of link-scoped addresses are
actually never happening because the Gateway in the fixed infrastructure
takes care to generate them.

> We can't say that it's OK for a router not to be able to support
> PMTUd, send unreachables, support traceroute, etc.  for transit
> traffic.

Well we could, if somebody else takes care to support these anyways (as
is the case today).

E.g., the cellular network does not allow any traceroute nor PMTUd down
to the User Equipment, regardless of it being a Host or a Router.

> Third, this mode doesn't even simplify implementation, because the
> sharing device has to do autoconf on the uplink anyway to get the
> prefix to share.

It does simplify implementation because it avoids proxy behaviour on the
Mobile Router.

> Fourth, disabling autoconf once sharing is enabled means that this
> method will not work on any network where the upstream prefix can
> change.

Well, look at it another way.  A Router does not use autoconf anyways.
So it is actually a bad behaviour to allow the Host to become a Router
and subsequently autoconf an address from the RA it receives.  In theory.

> Why was this mode included?

BEcause it helps avoid the duplicate address of a node in the LAN.

The bad situation could be the following: Router auto-configures an
address from the RA received on the cellular, and then a Host in its LAN
auto-configures the same address from the RA this Router advertises on
this LAN (it's same prefix).  Two equal globally-scoped addresses on two
different interfaces of different machines is not good.

> 3. Scenarios #2 and #3 are underspecified. For example, what does
> the RA on the LAN look like? Is it a copy of the RA from the WAN?
> Presumably not, since we'd want to include the link-layer address of
> the router in it. Does the sharing device decrement the TTL? And so
> on.

I agree, this could be better described.

> Instead of putting these as details in the scenarios, they should
> probably be put in a more general requirements section whose job it
> is to explain what the sharing device must do in order for the IPv6
> protocol to work correctly when sharing a /64. The scenarios would
> then become examples of ways you can do this.
>
> 4. Some of the language is inappropriately vague. For example, what
> does "defends its LAN IPv6 address with DAD" mean?

I agree, it could say: send 3 NAs upon startup for this address and
reply to NSs about that address, on the LAN.  Or similar.

> 5. It's not OK to say that privacy extensions should be disabled. I
> think the document should say that if the sharing device has privacy
> addresses, it should maintain them, and if it does maintain them, it
> must support DAD for those addresses on its downstream interface(s).
>
> 6. The document should say that said neighbor advertisements are
> proxy neighbour advertisements per RFC 4861 section 7.2.8. Note that
> this is different from ND proxy (RFC 4389), which is experimental.

I am not sure whether implementations already do proxy ND, ours doesnt.
  I am not sure there is a need to do it either.

Alex

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

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 28 May 2013 17:14:06 +0200

> Sent: Tuesday, May 28, 2013 1:22 PM
> To: Lorenzo Colitti
> Cc: IPv6 Ops WG

It addresses the open points discussed in the above mentioned appendix, so the IPv6 prefix can be 'safely' shared.
It leaves any proxying out as it is fully L3 routing based. Have a read if you want.

Cheers,
Ales

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 May 2013 11:53:23 -0700

> there was a  cornucopia of implementation variations.

The IETF did not deny the existence of NAT… They decried it as a bad idea.

History has shown that they were correct in this claim.

> phones) all shipping prefix sharing implementations.)

I don't think it's as bad or as dramatic as you make it out to be.

There's a working implementation that meets a need. All Lorenzo is suggesting
is that we take the time to understand that working implementation and document
it.

Does not seem unreasonable to me.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 28 May 2013 11:55:21 -0700

> I was sort of hoping nobody would open that can of worms, as the same thing occurred to me previously. I fear that doing this would provide an excuse to some ISPs not to give out more than a single…

+1

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 May 2013 13:33:54 +0900

> 2. I think scenario #1 should be removed.

Sorry, but no, it doesn't "work". It doesn't support PMTUd and or ICMP
errors, which are non-optional parts of the IPv6 specifications.

> address then somebody else in the LAN could use it.  This avoids all the

"Because we're lazy and don't want to take the time to understand and
document how things should work"?

> Well we could, if somebody else takes care to support these anyways (as

No - at the very minimum, you have to at least handle the case where the
sharing device's uplink MTU (e.g., 3G) is lower than the MTU on the shared
link (e.g., wifi). This cannot be supported by the network, it must be
supported by the sharing device.

> to the User Equipment, regardless of it being a Host or a Router.

If PMTUd is not allowed, then IPv6 doesn't work. It's not an optional part
of the spec.

> and subsequently autoconf an address from the RA it receives.  In theory.

RFC 6204 specifies that IPv6 CE routers use autoconf.

> different interfaces of different machines is not good.

That's why this draft should say that the sharing device must do DAD.

>  I am not sure there is a need to do it either.

It doesn't need to if you don't care if it works well or not :)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 May 2013 07:54:53 +0200

Le 29/05/2013 06:33, Lorenzo Colitti a écrit :
> On Wed, May 29, 2013 at 12:11 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> sharing device's uplink MTU (e.g., 3G) is lower than the MTU on the
> shared link (e.g., wifi). This cannot be supported by the network, it
> must be supported by the sharing device.

Yes, MTU is an issue that should be considered and maybe the IPv6 UE 
being a Router would not do the automatic fragmentation, but the node in 
the LAN would.

> If PMTUd is not allowed, then IPv6 doesn't work. It's not an optional
> part of the spec.

But by this logic no existing IPv6 cellular host (leaving aside the 
64share) would work on IPv6 because none does PMTUd.  I mean I havent 
seen these messages.

I note we talk two different things: MTU and PMTUd.

One could deal with MTU discepancies by setting right MTU manually on 
interfaces on UE and Host on LAN.  More automatically by running PMTUd.

The first is easier to deal with both in impl and in spec, but the 
second assumes not only the Host or the UE does it but also the 
Correspondent Node.  I am not sure many such end nodes are able to do it.

> RFC 6204 specifies that IPv6 CE routers use autoconf.

And that is not a cellular router.

> That's why this draft should say that the sharing device must do DAD.

YEs, that is right.  The UE must do DAD on the LAN, just in case.

> It doesn't need to if you don't care if it works well or not :)

Ok.

Alex

---

From: Ole Troan <[email-masked]>
Date: Tue, 28 May 2013 22:33:43 +0200

Vizdal,

> It leaves any proxying out as it is fully L3 routing based. Have a read if you want.

have now read, thanks. ;-)
I don't quite see where "safely" comes into the picture.
I think the second paragraph in appendix A, still applies to the solution in this draft.

I would recommend a strong applicability statement.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 08:53:20 +0200

> Yes, MTU is an issue that should be considered and maybe the IPv6 UE being a Router would not do the automatic fragmentation, but the node in the LAN would.

the host in the LAN would, but only if the first-hop router supported PMTUD. and no, it doesn't strictly speaking need a global address to do that for a directly connected host.

> But by this logic no existing IPv6 cellular host (leaving aside the 64share) would work on IPv6 because none does PMTUd.  I mean I havent seen these messages.

I have no idea what an IPv6 cellular host is. I connect my host to a phone via WIFI, where the phone acts as a router with a cellular uplink.

> One could deal with MTU discepancies by setting right MTU manually on interfaces on UE and Host on LAN.  More automatically by running PMTUd.

I'm not going to manually adjust anything. forget it.

> The first is easier to deal with both in impl and in spec, but the second assumes not only the Host or the UE does it but also the Correspondent Node.  I am not sure many such end nodes are able to do it.

every IPv6 node I'm aware of supports pmtud.

> And that is not a cellular router.

oh please. a cellular router is a router. an RFC6204 is a subset of a router, that has a certain interface with a dual host/router function.
that's exactly what your cellular router does. let us now fall back into the trap of designing different L3 functionality for all different L2s. like e.g. what we did with PPP for IPv4 vs DHCP for Ethernet.

> YEs, that is right.  The UE must do DAD on the LAN, just in case.

obviously. you would do yourself a favour not trying to redesign the base IPv6 functionality.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 May 2013 16:13:59 +0900

On Wed, May 29, 2013 at 3:53 PM, Ole Troan <[email-masked]> wrote:

> the host in the LAN would, but only if the first-hop router supported
> PMTUD. and no, it doesn't strictly speaking need a global address to do
> that for a directly connected host.
>

But it does need a global address to send ICMP errors to off-link
destinations (i.e., everywhere else on the Internet).

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 09:21:10 +0200

Lorenzo,

> But it does need a global address to send ICMP errors to off-link destinations (i.e., everywhere else on the Internet).

absolutely.
I think the draft should only describe scenario 2, and be explicit about the router using the weak host model.
it should also have a normative reference to RFC6204 making it clear that this device is a CE router, with some short term
hack for this particular link-type.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 May 2013 11:21:15 +0200

Le 29/05/2013 09:13, Lorenzo Colitti a écrit :
> On Wed, May 29, 2013 at 3:53 PM, Ole Troan <[email-masked]
>     the host in the LAN would, but only if the first-hop router
>     supported PMTUD. and no, it doesn't strictly speaking need a global
>     address to do that for a directly connected host.
>
>

I think this is a breaking point.

I dont think a Router must have a globally scoped unicast address always.

I think one goes too far in interpreting that as being a strong requirement.

I think this neglects what is already happening with many specs at IETF, 
at various maturity levels, and which dont assume every other RFC out 
there is a must.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 29 May 2013 18:29:19 +0900

On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu <
[email-masked]> wrote:

> at various maturity levels, and which dont assume every other RFC out there
> is a must.
>

I think that "routers forwarding packets to and from global addresses
should have global addresses" is pretty clearly a must-have because it's
the only way to implement various non-optional parts of ICMPv6 in a way
that works.

But even if you disagree that it's a must, it's at least operational good
practice, and I think we need a better reason to recommend violating this
operational good practice than "we want to allow implementations not to
implement DAD".

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 May 2013 12:00:02 +0200

Le 29/05/2013 11:29, Lorenzo Colitti a écrit :
> On Wed, May 29, 2013 at 6:21 PM, Alexandru Petrescu
> I think this neglects what is already happening with many specs at
> IETF, at various maturity levels, and which dont assume every other
> RFC out there is a must.
>
>
> should have global addresses" is pretty clearly a must-have because
> it's the only way to implement various non-optional parts of ICMPv6
> in a way that works.
>
> But even if you disagree that it's a must, it's at least operational
>  good practice, and I think we need a better reason to recommend
> violating this operational good practice than "we want to allow
> implementations not to implement DAD".

Routers can forward packets between globally-scoped addresses without
needing such for self.  Small routers at the edge of the network with
1-2 routing table entries are less likely to break something, much less
than core network routers which better had ICMP Redirect, Packet Too Big.

DAD is good to do, but DAD wont offer uniqueness, wont fix the
duplication problem.

Should the UE Router keep its global address to maybe one day respond
with a Packet Too Big?

Or should the UE Router delete its global address to avoid one day a
duplicate situation with a Host in the LAN?

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 12:36:01 +0200

Alexandru,

> duplicate situation with a Host in the LAN?

I thought redesign of IPv6 was outside of the scope of v6ops.

cheers,
Ole

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 May 2013 14:07:38 +0200

> I thought redesign of IPv6 was outside of the scope of v6ops.

I thought operational experience of IPv6 deployments were relevant.

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 29 May 2013 14:13:24 +0200

> I thought operational experience of IPv6 deployments were relevant.

do you have operational experience showing:
 - there is no consequence of a router not being able to send ICMPs
 - duplicate addresses is a bigger problem between hosts and the router than between a host and other hosts,
   justifying that the router shouldn't have a global address on the link?

if so, please share.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Wed, 29 May 2013 15:20:01 +0200

Hi,

> I thought operational experience of IPv6 deployments were relevant.

Then you should try to get some.

Really: the amount of noise you are contributing to this discussion is
unbearable.  I'm all for a good discussion, but not based on "well, I don't
really care about all these bits everybody and the standards are agreeing
on, so let's do it all differently now".

Gert Doering
        -- NetMaster
-- 
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: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 29 May 2013 13:32:01 +0000

> it should also have a normative reference to RFC6204 making it clear that
> this device is a CE router, 

+1.

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ole Troan
> Sent: Wednesday, May 29, 2013 3:21 AM
> To: Lorenzo Colitti
> Cc: [email-masked] WG
> PMTUD. and no, it doesn't strictly speaking need a global address to do that
> for a directly connected host.
> >
> it should also have a normative reference to RFC6204 making it clear that
> this device is a CE router, with some short term hack for this particular link-
> type.
> 
> cheers,
> Ole
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 May 2013 15:15:31 +0000

> I thought operational experience of IPv6 deployments were relevant.

My operational experience of CE routers and IP deployments (v4 and v6) suggests that a CE router that can't at the very least do diagnostics and troubleshooting against Internet destinations is a bad idea. Being able to launch various simple tests from the router is critical when troubleshooting, so that the LAN can be properly dismissed as the cause of a problem. 

Therefore, I would never recommend that anyone get a CE router that can support a 3GPP IPv6 WAN interface (directly or via USB modem), but doesn't try to assign itself a GUA that can be used to source traffic that gets sent out the WAN interface. That is, I would never recommend a "Scenario 1" IPv6 router to anyone.

When working with "wireline" CE router vendors to define the "unnumbered" model (where the CE router is expected to take its addresses from a prefix it has been delegated via IA_PD), the router vendors said it wasn't a problem to do this. They did ask us not to try to be specific about what interface the addresses got attached to. Some only had a single WAN and LAN interface, in which case they intended to attach the addresses to the LAN interface. Others had a variety of internal interfaces, as well. This was especially true of the CE routers that supported multiple LAN networking technologies (e.g., Ethernet and Wi-Fi), and those that could support multiple WAN interfaces. The router vendors asked that we just describe the externally detectable behavior (treat it like a black box) and let them figure out how to do things internal to their products. This is reflected in the RFC 6204 requirement:
   WAA-8:  If the IPv6 CE router does not acquire global IPv6
           address(es) from either SLAAC or DHCPv6, then it MUST create
           global IPv6 address(es) from its delegated prefix(es) and
           configure those on one of its internal virtual network
           interfaces.

If I were to translate that experience to this case, I would prefer to expect the following of an IPv6 CE router capable of a 3GPP interface:
If the WAN interface is a 3GPP interface, and there is an RA message with an "A=1" prefix and flags M=O=0, treat the "A=1" prefix in the RA message as if it were a /64 delegated prefix, and operate per RFC 6204 WAA-8 and WAA-9 (do weak host model). Do not do SLAAC on the WAN interface (i.e., there will be no DAD messages seen coming out the WAN interface). If LAN interface is active, advertise the /64 prefix on the LAN with A=1 and do DAD (to the LAN) for all self-assigned addresses from that prefix. Or, better yet, do RFC 6204 LAN-Side Configuration (Section 4.3). I don't know if all of the WAN-Side Configuration requirements (Section 4.2 of RFC 6204) should be applied to a 3GPP interface, so I'm hesitant about suggesting RFC 6204 be made normative in its entirety.

This is effectively Scenario 2, where the UE always considers its router functionality to be enabled (because it was designed to primarily be a router), so it never does SLAAC on the WAN interface (unless M or O indicate the presence of a DHCPv6 server) and doesn't move its addresses around based on the state of router functionality.

Anyway, that's my 2 cents, as someone who deals a lot with CE routers in mass market environments. UEs that do tethering are a whole different world, and I don't pretend to provide advice to them.
Barbara

---

From: "cb.list6" <[email-masked]>
Date: Wed, 29 May 2013 09:14:35 -0700

On Wed, May 29, 2013 at 2:29 AM, Lorenzo Colitti <[email-masked]> wrote:
> <[email-masked]> wrote:
>>

I agree, it is not OK to break PMTU

I will remove scenario 1.

CB

> I think that "routers forwarding packets to and from global addresses should
> have global addresses" is pretty clearly a must-have because it's the only
> way to implement various non-optional parts of ICMPv6 in a way that works.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 May 2013 18:40:55 +0200

> I agree, it is not OK to break PMTU

I am happy somebody agrees with me, and I must say I smile :-)

> I will remove scenario 1.

Yet I dont understand what's going on.

Breaking PMTUd (Path MTU Discovery) on UE IPv6 Router happens if that 
Router did receive some larger-than-1280 packets on the cellular 
interface and its WiFi were 1280.  I havent seen such packets.  Maybe 
they exist, maybe not.

One could go get some more operational experience, or someone else could 
try it if not done already.

Or one would look at the specs:

RFC1981 PMTUv6 "As discussed in section 1, IPv6 nodes are not required 
to implement Path MTU Discovery.  The requirements in this section apply 
only to those implementations that include Path MTU Discovery."

RFC6434 IPv6 Node Requirements about PMTUd:
"5.6. Path MTU Discovery and Packet Size
5.6.1. Path MTU Discovery - RFC 1981
    "Path MTU Discovery for IP version 6" [RFC1981] SHOULD be supported."

It's a SHOULD not a MUST.

"  From [RFC2460]:

       It is strongly recommended that IPv6 nodes implement Path MTU
       Discovery [RFC1981], in order to discover and take advantage of
       path MTUs greater than 1280 octets.  However, a minimal IPv6
       implementation (e.g., in a boot ROM) may simply restrict itself to
       sending packets no larger than 1280 octets, and omit
       implementation of Path MTU Discovery."

... sending packets no larger than 1280 and omit PMTUd...

'break PMTU' - means to me to have a link in the middle that is lower 
MTU than 1280.  That is ok to break, because PMTUd will signal it and 
that's it. (as DAD signals duplicates and that's it).

'break PMTUd' - means to me to eliminate the PMTUd(iscovery) 
functionality from some node.  That is ok to break as well, because it 
is not mandatory.

Alex

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 May 2013 08:21:09 +1000

It's not just PMTUD.  It's any ICMPv6 message.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Owen DeLong <[email-masked]>
Date: Wed, 29 May 2013 16:34:11 -0700

Alex,

An end-node which does not support PMTUd and only sends ≤1280 octet datagrams is fine.

A router which is not an end-node and does not have the ability to send PTB notifications back, on the other hand, is an entirely different creature.

Since we are talking about a UE acting as a router in this case, we cannot ignore the need for routers to implement PMTUd which means that the router MUST have a global address from which it can source PTB messages.

Yes, it is possible for a UE to have a larger cellular MTU and a downstream link which has a smaller MTU. Whether such exists in the wild today or not, it is permitted in a variety of standards that already exist and therefore must be considered in developing further standards as it is a valid scenario.

Owen

On May 29, 2013, at 9:40 AM, Alexandru Petrescu <[email-masked]> wrote:

> Breaking PMTUd (Path MTU Discovery) on UE IPv6 Router happens if that Router did receive some larger-than-1280 packets on the cellular interface and its WiFi were 1280.  I havent seen such packets.  Maybe they exist, maybe not.
> 
> One could go get some more operational experience, or someone else could try it if not done already.
> 
> RFC1981 PMTUv6 "As discussed in section 1, IPv6 nodes are not required to implement Path MTU Discovery.  The requirements in this section apply only to those implementations that include Path MTU Discovery."
> 
> 'break PMTU' - means to me to have a link in the middle that is lower MTU than 1280.  That is ok to break, because PMTUd will signal it and that's it. (as DAD signals duplicates and that's it).
> 
> 'break PMTUd' - means to me to eliminate the PMTUd(iscovery) functionality from some node.  That is ok to break as well, because it is not mandatory.
> 
> Alex
> 
>> 
>> CB
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 May 2013 07:06:23 +0200

> 	It's not just PMTUD.  It's any ICMPv6 message.

Put that way I tend to agree.

But one would need to look at the detail of all such messages.  Or only 
the ICMPv6 messages in RFC4443 ICMPv6?

I mean: ok for EchoReq, ParameterProblem, TimeExceeded.

However, DestUnreachable I dont think is valid.  This Gateway thinks 
there is a single address to the link, not the entire set of addresses. 
  As such it would be not quite good to say that a Dest is unreachable 
since the Gateway didnt pretend to either, or did it.

The many other ICMPv6 messages in other RFCs: eg Redirect of ND, or the 
ICMPv6 RPL control message, or the DHAAD.  I doubt they're all supported 
or needed.

But yes, I tend to agree that many ICMPv6 messages may need that GUA and 
is good.

Alex