Subject: Re: new draft on IPv6 CPE router available for review

From: "Ole Troan" <[email-masked]>
Date: Tue, 1 Jul 2008 12:28:13 +0200

>> Even in this case, some software which is going to send a packet to the
>> network
>> from CPE, according to RFC3484 "Default Address Selection for IPv6",
>> there is a certain reason why the WAN I/F's IP address should be used as
>> its source address like follows.
>>  ---------------- from RFC3484 ----------------
>>  It is RECOMMENDED that the candidate source addresses be the set of
>>  unicast addresses assigned to the interface that will be used to send
>>  to the destination.  (The "outgoing" interface.)  On routers, the
>>  candidate set MAY include unicast addresses assigned to any interface
>>  that forwards packets, subject to the restrictions described below.
>
> What is the reason for this recommendation?

increased chance of path symmetry for one.
check the ipng thread from 1999 "simple source address selection".
e.g Message-Id: 	<v04204e00b34e3e78cc17@[171.69.116.90]>

if an implementation handles unnumbered links (links without global
addresses) or loopback interfaces then it has to implement the
semi-strong or weak host model. are there router implementation which
implements the strong host model?

/ot

---

From: David Miles <[email-masked]>
Date: Tue, 1 Jul 2008 23:35:12 +1000

Wes, Hemant and Shin,

I would add my support to Mikael's request that the draft has the  
option of having a global unicast WAN address OR having link-local  
only WAN on a routing CPE. Would it be okay to incorporate the content  
of Shin's draft into the CPE discussion/draft?

Ole raised the issue that a router would (almost by definition) need  
to implement a weak or semi-strong model, and I would support this  
view. I do believe the CPE must support the sending of IP datagrams to  
Internet hosts (for ICMPv6, management, etc) but see an option of  
using a loopback interface for this purpose (from the subscriber's  
delegated prefix). This allows a single subscriber to be represented  
by one prefix that may be operationally beneficial, or provide a more  
scalable BNG architecture.

By supporting both options we can allow operators to deploy a model  
that makes the most sense for them.

Best Regards,

-David Miles

On 01/07/2008, at 4:53 PM, Mikael Abrahamsson wrote:

> On Tue, 1 Jul 2008, Shin Miyakawa wrote:
>
>> to terminate the IPv6 uplink by itself, so from practical point of  
>> view, we strongly recommend to assign a global IPv6 address.
>
> Well, my personal opinion is that this makes Vista unfit to be a  
> IPv6 CPE. We cannot adjust IPv6 address policy just because of  
> certain design decisions on behalf of Microsoft.
>
> It is my belief that customers (at least in the market I am in) will  
> need to have a small CPE that is not an end host, and this is what  
> the draft should be aimed at. Advocating PPP is also a very bad idea  
> as this cements the use of LAC/LNS and tunneling, which is a really  
> bad idea for future multicast use, as well as being more expensive  
> than necessary.
>
> My idea of a good IPv6 service is one that is purely IPv6 over  
> ethernet, optionally with 1-2 q tags or mac-in-mac in the ISP part  
> of the network, but definitely not involving PPP or L2TP anywhere in  
> the path.
>
> At least, how can we make the draft comply so that what I would like  
> to do doesn't violate any draft? I can understand if both options  
> are in there, but making my proposal a draft violation seems like a  
> bad idea, as we both seem to agree that it's the proper thing to do?
>
> -- 
> Mikael Abrahamsson    email: [email-masked]
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 1 Jul 2008 15:55:18 +0200 (CEST)

> implements the strong host model?

Most routers will use outgoing interface IP address for creating IP 
packets, unless it's been specified that this service should originate 
from another interface. To use cisco example:

With the following configuration line:

ip telnet source-interface Loopback0

all telnet session initiated from the router CLI will have source IP of 
"loopback 0" interface. If this line is not present, the router defaults 
to using the outgoing interface (routingwise) IP address as source IP for 
the telnet TCP session.

It's standard industry practice to use loopback addresses for almost 
everything control plane in routers, as then the IGP will handle reroutes 
and established TCP sessions are not affected by interfaces going up or 
down.

---

From: Shin Miyakawa <[email-masked]>
Date: Wed, 02 Jul 2008 04:10:42 +0900 (JST)

Hello, David :-)

> of Shin's draft into the CPE discussion/draft?

David, as we have discussed this several months off from this mailing list
in various places on the Earth, you know the reason why I said.

Then.... "OR" means sometime ambiguous.......

Actually, my opinion is

(A) the draft should have "discussions" text to explain why those are recommended
    and this draft should be more generalized not only for cable TV systems.

    For example, section 1 in this draft's clearly said that
    "WAN interface is Ethernet encapsulated", but it should be converted to
    "WAN interface may be Ethernet encapsulated but not limited too" 
    or something like that because we need to think about other semantics like PPP.

(B) Because a strong host model is one of possible implemenation of CPE, so

    "Global unicast WAN address" MUST be supported
       and                       ^^^^
    "Link-Local only WAN on a routing CPE" MAY be supported

as the "access concentrator"'s specification
which provides the service to the IPv6 CPE.

Best wishes,

Shin Miyakawa

P.S.

However I also prefer Mikael's model personally, 
we have to be very realistic and tolerant to 
any implemenations compatible with the standard.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 1 Jul 2008 21:49:32 +0200 (CEST)

On Tue, 1 Jul 2008, Hemant Singh (shemant) wrote:

> router supporting the link-local only WAN model. Of course, we totally 
> want the first model to be a MUST for the CPE router to support - in 
> this model the WAN interface acquires a global IPv6 address.

What are the downsides of making both models a MUST? I think any router 
should (MUST) be able to source packets from any interface chosen, 
including one that is not the outgoing interface.

This would of course have the implications that some primary host 
implementations with optional routing capability might not comply with 
this right now, but would put pressure on vendors to implement this 
properly.

I know there's been discussions regarding traceroute behaviour as well, 
with the industry standard being that the ICMP TTL-EXCEEDED message being 
sourced from the router IP where it was received, but goes out any 
interface (as per the routing table to the destination).

I just would like to get future IPv6 implementations for routers working 
properly from the start, as most residential CPE vendors seem to not have 
implemented IPv6 support yet, I would like them to do both models as the 
model I'm advocating would have long term benefits for network stability.

---

From: Shin Miyakawa <[email-masked]>
Date: Wed, 02 Jul 2008 11:09:36 +0900 (JST)

Mikael,

> and established TCP sessions are not affected by interfaces going up or 

In CPE router case, it is not true, isn't it ?
Because in today's environment a CPE has only one IPv4 address
which is assigned to the WAN interface of the CPE.

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Wed, 02 Jul 2008 11:12:10 +0900 (JST)

Hemant and Mikael,

Let me clarify that your idea is that 

   One CPE MUST support BOTH models ?

This is quite important, because it defines operation scheme.

Shin Miyakawa

From: "Hemant Singh (shemant)" <[email-masked]>
Subject: RE: new draft on IPv6 CPE router available for review
Date: Tue, 1 Jul 2008 16:05:07 -0400

> Honestly, I don't see any downside to making support for both models as
> a MUST. If anyone any objections to making both models a MUST, it's time
> to speak up.
> 
> Hemant 
> 
> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[email-masked]] 
> Sent: Tuesday, July 01, 2008 3:50 PM
> To: Hemant Singh (shemant)
> Cc: Shin Miyakawa; Wes Beebee (wbeebee); [email-masked]
> Subject: RE: new draft on IPv6 CPE router available for review
> 
> with the industry standard being that the ICMP TTL-EXCEEDED message
> being sourced from the router IP where it was received, but goes out any
> properly from the start, as most residential CPE vendors seem to not
> have implemented IPv6 support yet, I would like them to do both models
> as the model I'm advocating would have long term benefits for network
> stability.
> 
> --

---

From: Shin Miyakawa <[email-masked]>
Date: Wed, 02 Jul 2008 11:49:54 +0900 (JST)

David,

> delegated prefix). 

Please note well that, if you'd like to assign a global IPv6 unicast address
to the LoopBack interface,
because loopback is the diffrent from LAN links behind the CPE,
we have to assign at least two /64 prefies to the CPE
(one /64 for LAN, one /64 for loopback, assuming that a /64 is the minimal unit 
of prefix delegation).

> This allows a single subscriber to be represented  

So, this consumes more than 
"one Global address for the WAN interface with one /64 for LAN" (as
I called this as "1+/64" or for some reason, "1+/64s") model.

How do you think about this fact ?

Or forget about the loopback interface and use the CPE's LAN interface in
the weak host model case ?

Best wishes,

Shin Miyakawa

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Jul 2008 06:16:15 +0200 (CEST)

> which is assigned to the WAN interface of the CPE.

Well, I think in the IPv6 case that CPEs need to be more advanced than 
todays devices. I foresee 3G/4G backups for the WAN port for instance.

Also, the reason for only assigning single global IPv4 space to customers 
is usually because of scarcity of IPv4 addresses, and the ISPs I know of 
who allow for multiple addresses, do this via kludges (local-proxy-arp for 
instance, which means that local traffic between customer computers risk 
going over the WAN).

Also, I would have liked to do the core/customer IP block thing for IPv4 
as well, it's just that the support for that in cheap customer CPEs just 
isn't there.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Jul 2008 06:17:23 +0200 (CEST)

> This is quite important, because it defines operation scheme.

Yes, I want the devices to support both models, and then the ISP can 
choose one. It also means CPE can hopefully be reused when a customer 
changes ISPs, or interacts with multiple ISPs (think one 4G wireless ISP 
and another wired ISP).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 2 Jul 2008 06:23:45 +0200 (CEST)

> (one /64 for LAN, one /64 for loopback, assuming that a /64 is the minimal unit

I want to assign either a /56 or /48 per residential user.

> How do you think about this fact ?

I think it's very important that customers are able to use multiple IPv6 
subnets in their home for a lot of reasons, where a DMZ might be one.

> the weak host model case ?

That works for me as well, as long as the customer only originates 
globally routed traffic from the PD assigned block, I'm fine.

Also, by doing link-local, I hope to save TCAM space in the 
distribution/PE router as well. Each adjacancy it has to keep will afaik 
consume router resources, not having a globally routable WAN address saves 
at least one TCAM entry, plus perhaps one more because my ACL in on the 
subinterface will not have to allow for both the customer /56 as well as 
the /64 and the link-local, it can now only allow for the customer /56 and 
the link-local, that's probably one more TCAM entry saved.

---

From: David Miles <[email-masked]>
Date: Wed, 2 Jul 2008 23:46:19 +1000

Shin,

> (one /64 for LAN, one /64 for loopback, assuming that a /64 is the  

Yes, agree.

> How do you think about this fact ?

Sorry Shin, I had thought the /64 was an example for any delegated  
prefix-length. For prefix-lengths shorter than /64 do you see  
different options?

> the weak host model case ?

This is an option as well if we are concerned about the use of an  
entire /64 for CPE management. Given there has been some discussion  
recently on-list about using a /64 on point-to-point links as best  
practice, it would seem to suggest that a /64 should not be considered  
an excessive waste of IPv6 resource. There is also a potential for the  
LAN interface to be in a down state, and for the service provider to  
require management of the device. By binding the global-scope  
management address to either the loopback or the WAN interface the  
service provider can ensure management irrespective of LAN interface  
state. Further, the customer may choose to address their LAN interface  
however they see fit, which may not suit a service provider. Thus I  
prefer the options of using loopback or WAN interface.

Again, I reiterate that I think both options are acceptable and may  
have different consequences that an operator should be informed on. I  
am not arguing against the /64+1 or even a /56+1, I am supporting the  
option of a link-local-only WAN interface.

Best Regards,

-David

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Wed, 2 Jul 2008 07:39:35 -0700 (PDT)

David,

--- On Wed, 7/2/08, David Miles <[email-masked]> wrote:
 
> There is also a potential for the LAN interface to be in a down state,
> and for the service provider to require management of the device.
> By binding the global-scope management address to either the loopback
> or the WAN interface the 
> service provider can ensure management irrespective of LAN
> interface state.
> 
> -David

The CPE must also support IPv4, and for using one subnet in IPv4 world, it's a practice to have a LAN bridge with Ethernet, Wifi, etc. interfaces adding to it.
And this bridge is always up, even if the LAN interfaces are individualy down.
So binding the global-scope management address to this LAN bridge can be a way to consider.

Best Regards,

Francois-Xavier

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 03 Jul 2008 05:11:15 +0900 (JST)

oops.
> Also how about if a customer has only one PC (this is quite linkly situation) ?
                                                              likely

Shin

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 03 Jul 2008 05:09:38 +0900 (JST)

Mikael,

> choose one. 

This is a point. This means you are not allowing any CPE device which is
(A)A machine will follow RFC3484 to select source address
   regardless if this machine is a strong host model or a weak host model
(B)No routing function (for example, because there is no LAN behind)

So, 

(X)Even if a machine terminates PPPoE, L2TP or whatever uplink by itself 
   with no other machines in the customer premises, this machine must have BOTH models.

Then, it seems to me that this is overkill.

For example, if we create sensor networks, do we still need routing function
on all the sensor devices ? I do not think so.

At the same time, please note that we have no way to identify a CPE is a router
or just a host.

So, I strongly against this text "One CPE MUST support BOTH models".

Of course, "The Service MUST support BOTH models" will be fine.
            =========== 

Best regards,

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Thu, 03 Jul 2008 05:25:39 +0900 (JST)

> prefix-length. For prefix-lengths shorter than /64 do you see  

Of course fine, for me. 

> entire /64 for CPE management. 

sounds fine for me too.

> Given there has been some discussion  
> an excessive waste of IPv6 resource. 

OK. I agree with this.

> There is also a potential for the  
> require management of the device. 

In this case, assigning a global IP address to the WAN I/F is easy way, isn't it ?

> By binding the global-scope  
> state. 

If you think that some address from "delegated range" can be bind to the WAN 
interface, 

                              +-------uplink -------------(1) CPE #1
Access concentrator (x)-------+-------uplink -------------(2) CPE #2
                              +-------uplink -------------(3) CPE #3

If the interface at (x) has no global ip address and
interfaces (1), (2) and (3) has global IP address from their delegated range,
I don't think this is a good situation.

> Further, the customer may choose to address their LAN interface  

So, if you think that that address is from "delegated range" just like Mikael says,
You should not use it on WAN I/F but loopback. 

> Again, I reiterate that I think both options are acceptable 

This is what I say. Mikael say more strict model. Please do not be confused.

> I am supporting the option of a link-local-only WAN interface.

Then, again, please try to modify RFC3484 first.

Shin Miyakawa

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Jul 2008 07:46:11 +0200 (CEST)

> (B)No routing function (for example, because there is no LAN behind)

Correct.

>   with no other machines in the customer premises, this machine must have BOTH models.

I never said all IPv6 speaking HOSTS need to do this. For me a CPE is 
something that is involved in the delivery of a service, not an end user 
host device. I see two different services, one which is for connecting a 
single device and nothing else, and another service where the customer has 
a router and several hosts behind it. If this is another definition of a 
CPE, then I need to change my terminology to avoid confusion. Am I using 
the wrong terminology?

> For example, if we create sensor networks, do we still need routing 
> function on all the sensor devices ? I do not think so.

Of course not.

> At the same time, please note that we have no way to identify a CPE is a router

The customer will have to decide this at the time of purchase of the 
service.

> Of course, "The Service MUST support BOTH models" will be fine.

That is not what I want, quite the opposite.

So, let me elaborate my view, and include my definitions which might make 
it more clear what I'm after.

For me, a CPE is the device that connects the home network to the outside 
world, it might be a DSL modem, a NAT gateway, wireless access point or 
alike. It is NOT an end host.

In 10 years time, I see people having all kinds of devices in their home, 
and the ISP does not want to keep state or forwarding resources for every 
device, thus we need to route IPv6 subnet to a router that is placed in 
the home, controlled by the customer (or a provisioning system in case of 
a managed CPE, but the customer will most likely be influencing how the 
CPE is configured thru a selfcare system that then configures the CPE).

For people with only a single computer in their home, I want this to be a 
special case, and since they don't need triple play or alike, we might as 
well tunnel them over IPv4/ethernet in the interim, with 6to4, PPPoE or 
alike. So the ISP provides two different services whether the customer 
wants to have a home gateway with a LAN behind it, or if they want to just 
connect a single computer.

So, my rationale is that any home gateway device needs to support both 
models (link-local only for WAN and the strong host model), end hosts only 
need to support the strong host model.

Does this make my position more understandable?

---

From: [email-masked]
Date: Thu, 03 Jul 2008 02:47:04 -0600

> CPE, then I need to change my terminology to avoid confusion. Am I using 

It seems to me that there is a confusion in terminology that is feeding this 
mail chain. 

Common usage has CPE being both the edge device (1)(DSL modem with or 
without built in router),  Router/Switch (2)(built in DSL, Ethernet, WiFi, 
etc.), and the end-user device (3) (PC, Laptop, PDA, dual function Mobile 
phone). 

This document seems to deal with 1 and 2 only while discussion is mostly on 
3. It seems to me that we need to separate these topics to edge and End-user 
rather than the general CPE (what happens when these are mobile like with 
802.16e). 

We know that almost all (I am tempted to say all) PCs and laptops support 
dual stack today, but I would love to hear about the other end-user devices 
the so called "internet devices" from companies like Nokia. Are they dual 
stack already? 

Eric

---

From: <[email-masked]>
Date: Thu, 3 Jul 2008 14:14:03 +0300

Hi,

>etc.), and the end-user device (3) (PC, Laptop, PDA, dual 

This is a good separation and I agree we need to get terminology
clarified, as for me it is unclear whether a mobile phone that would
support DHCPv6 PD for getting prefixes for the local area network can be
called a CPE or not. I hear term "cellular router" also used in this
context. 

>We know that almost all (I am tempted to say all) PCs and 
>laptops support dual stack today, but I would love to hear about the
other 
>end-user devices 
>the so called "internet devices" from companies like Nokia. 
>Are they dual stack already? 

On the mobile side the situation generally is fuzzier than on "PC"-side.

When looking just at the operating systems commonly used in mobile
phones such as Symbian, Linux, Windows Mobile, and OS/X, they all by my
understanding include both IPv4 and IPv6 stacks (most likely the other
(proprietary) OS'es that are used have IPv6 support implemented as
well).

However, it is then totally different matter whether the actual products
that are using those operating system have IPv6 enabled/compiled in -
currently many products are sold as IPv4-only due to lack of demand for
IPv6-support from operators and customers, but also many products being
sold have both IPv4 and IPv6 enabled.

Do you think it would be beneficial to have a BCP or something that
would describe how the category (3) devices should behave? As category 3
devices are used in various networks and also often move pretty freely,
it may be that different networks provide different services, and e.g.
DHCPv6 PD is not available in all networks. Still these devices must
provide good user experience, thus I believe they have to support ND
proxies as well to always being able to provide connectivity for local
network. There probably are other things to consider as well that would
be good to document?

Best regards,

Teemu

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 07:37:43 -0400

Oh, there is more confusion. Cable folks refer to a CPE as a host behind
a cable modem where the host is a Windows or Mac OS PC. That is why in
our draft we specifically refer in all places to a "CPE Router".  In
other worlds, I know CPE is also a generic term where the CPE means a
DSL, cable, or FIOS modem. The modems may also have such a router
embedded inside them but the box is still a CPE. 

Our goal is to complete a document for a CPE Router that can be managed
by the Service Provider, or managed by the user, or the CPE Router may
be embedded in a broadband modem. We will see how the document evolves
after feedback. 

It is good to nail down Terminology otherwise we'll be thrashing a lot
during discussion. Why not refer to the DSL or cable modem as the modem.
Refer to the host behind the modem as a host, and the standalone
Linksys-like router in the home as the CPE Router. Any router cascaded
behind the CPE Router is, of course, just a router.

Mobile is also not a good term for the home since Mobile reeks more of
cellular Mobile. In the home, the most common term I have heard of in
the US homes in wireless and WLAN. What do you mean this document is not
discussing wireless in the CPE Router? It's not this document's business
to discuss physical layer of wireless. WLAN is just another network for
the CPE Router to forward packets to and from

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 4:47 AM
To: Mikael Abrahamsson
Cc: Shin Miyakawa; Hemant Singh (shemant); Wes Beebee (wbeebee);
[email-masked]
Subject: Re: new draft on IPv6 CPE router available for review

Mikael Abrahamsson writes: 

> something that is involved in the delivery of a service, not an end 
> user host device. I see two different services, one which is for 
> connecting a single device and nothing else, and another service where

> the customer has a router and several hosts behind it. If this is 
> another definition of a CPE, then I need to change my terminology to 
> avoid confusion. Am I using the wrong terminology?
> 

It seems to me that there is a confusion in terminology that is feeding
this 
mail chain. 

Common usage has CPE being both the edge device (1)(DSL modem with or 
without built in router),  Router/Switch (2)(built in DSL, Ethernet,
WiFi, 
etc.), and the end-user device (3) (PC, Laptop, PDA, dual function
Mobile 
phone). 

This document seems to deal with 1 and 2 only while discussion is mostly
on 
3. It seems to me that we need to separate these topics to edge and
End-user 
rather than the general CPE (what happens when these are mobile like
with 
802.16e). 

We know that almost all (I am tempted to say all) PCs and laptops
support 
dual stack today, but I would love to hear about the other end-user
devices 
the so called "internet devices" from companies like Nokia. Are they
dual 
stack already? 

Eric

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 07:51:30 -0400

It does not make sense to bundle PC and laptop in the category of a
device that will ask for IA_PD option from DHCPv6 server. Further this
draft clearly says it's describing a home CPE Router in Internet enabled
homes. Most common home Internet connection is cable or DSL. So where
does the question come from for a cellular router in one's home? Are you
talking about wireless Internet services for the home? Even if that is
the case, so what? As far as there is a link from that wireless service
device to the CPE Router, this draft covers even that deployment.

I don't think the CPE Router discussion is ambiguous. We are just not
discussing a mobile phone in this CPE Router discussion!

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 7:14 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Hemant Singh (shemant); Wes Beebee (wbeebee);
[email-masked]

Hi,

>WiFi, etc.), and the end-user device (3) (PC, Laptop, PDA, dual 
>function Mobile phone).

>support dual stack today, but I would love to hear about the
other 

Best regards,

Teemu

---

From: [email-masked]
Date: Thu, 03 Jul 2008 07:29:58 -0600

> sold have both IPv4 and IPv6 enabled.

Thank you this is what I suspected. 

> network. There probably are other things to consider as well that would

Having looked at what 3GPP has documented, and listening to what the WiMAX 
Forum have been working on, it is clear to me that no one has fully 
considered the implications of mobile devices with IPv6, especially in 
regards to roaming to between either v4 and dual stack vs. completely dual 
stack networks vs v6 only networks. And the fact that CPE and end-user 
devices can be either v4 only (see my original comment above) or dual stack, 
but these different groups are contemplating v6 only networks and devices 
(which is several years in the future at this point). 

So in short, yes I think a BCP / use case document would be very helpful to 
both the vendors and service providers who are looking towards the future. 

Best regards,
Eric

---

From: [email-masked]
Date: Thu, 03 Jul 2008 07:38:26 -0600

> be embedded in a broadband modem. We will see how the document evolves

This explains the difference in terminology usage. I suspect that the rest 
of the list is either from IP router/ DSL based or Mobile (Cellular/Wireless 
Broadband) mentalities. 

> the CPE Router to forward packets to and from

Actually I was using Mobile as a combination of Cellular (3GPP etc) and 
Wireless Broadband (WiMAX etc.) rather than WiFi. 

In this case Mobile is represented by a laptop with built in wireless 
(either tech is already installed or road mapped) or via PCMCIA etc or 
Internet terminals/dual function phones (Nokia, Samsung, etc.). 

Eric

---

From: [email-masked]
Date: Thu, 03 Jul 2008 07:41:27 -0600

> discussing a mobile phone in this CPE Router discussion!

Then you envision this document as being only for fixed services via Cable, 
DSL, WiMAX 802.16d, VSAT, where there is an edge device (cable modem, DSL 
modem, etc) that is both modem and router? 

Eric

---

From: <[email-masked]>
Date: Thu, 3 Jul 2008 18:17:47 +0300

>It does not make sense to bundle PC and laptop in the category 
>of a device that will ask for IA_PD option from DHCPv6 server. 

Why not?

>Further this draft clearly says it's describing a home CPE 
>Router in Internet enabled homes. Most common home Internet 
>connection is cable or DSL. So where does the question come 
>from for a cellular router in one's home? Are you talking 
>about wireless Internet services for the home? Even if that is 
>the case, so what? As far as there is a link from that 
>wireless service device to the CPE Router, this draft covers 
>even that deployment.
>
>I don't think the CPE Router discussion is ambiguous. We are 
>just not discussing a mobile phone in this CPE Router discussion!

The speeds of cellular networks are becoming reasonably fast by
introduction of HSDPA, EV-DO, 802.16e, LTE, and whatever further
generations there are coming. Furthermore flat rates are also gaining
popularity.

While cable and DSL are the current choices for Internet connectivity
for majority of people, I believe there are already, and in future will
be more, people who are willing to pay for flat rate Internet just once,
and they may choose to pay it only for their cellular connectivity - as
they can take that with them wherever they go.

It should be noted that the cellular device may not only be just handled
_phone_, but it can be integrated into car, bus, train, laptop, or even
be a square box that sits in fixed place - it just gets WAN connection
via cellular network and shares it to local (W)LAN. The network itself
should not care too much what the router behind the wired or wireless
link looks like.

I'm not saying that draft-wbeebee-ipv6-cpe-router should describe these
uses, but I'm interested to learn that if it does not, then maybe it
would be nice to have another document that would describe the uses
cases and recommendations for such category of devices.

In v4-only world some of these cellular devices already implement NAT
and DHCP server to share to LAN the single IPv4 address they got from
the network via point-to-point link. In v6 they should implement ND
proxies and DHCPv6 PD (to avoid need to do IPv6 NAT). For providing IPv4
connectivity for legacy devices in LAN when having only IPv6-native
access network, these devices shall implement some of those
IPv4-over-IPv6 technologies and then NAT the IPv4 address obtained e.g.
with DSMIPv6, MNAT-PT etc. for the devices in LAN and RFC1918 space.

Best regards,

	Teemu

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 04 Jul 2008 01:14:11 +0900 (JST)

Mikael,

First of all, thank you for your reply. 
I think that your vision is quite important.

> host device. 

"Something that is involved in the delivery of a service", 
can be an end user host device.
^^^^^^

Or, how about any applications on the CPE router ?

Please think about following picture.

Access Concentorator <----- PPP or whatever upstream link -----> A CPE that is "Something that is involved in the delivery of a service"

This CPE may be a router or a host. there is no difference between
two of those from ISP point of view.

Acutally, there are many service using just a PC to terminate ISP upstream.
So, why you exclude this case from (v6)CPE ?

> I see two different services, one which is for connecting a 

As other folks write to this mailing list, we have to clarify terminology.

> The customer will have to decide this at the time of purchase of the 

If so, I think that people will purchase "one IPv6 global address service
for a host" and USE V6NAT to connect any device in their home network,
because probably this service will be less expensive than 
"Prefix Delegated service for a routed CPE".
That's too bad. 

So, I don't like this idea...
"The customer will have to decide this at the time of purchase of the service."

Best regards,

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 04 Jul 2008 01:17:37 +0900 (JST)

Hemant,

> behind the CPE Router is, of course, just a router.

Please, please do not forget the fact that a host can be a router and
a router can be a host.

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 04 Jul 2008 01:21:08 +0900 (JST)

Hemant,

> device that will ask for IA_PD option from DHCPv6 server. 

No. It DOES MAKE sence.

> Further this draft clearly says it's describing a home CPE Router in Internet enabled
> homes. 

> Most common home Internet connection is cable or DSL. 

At least in Japan, most common home Internet connection is Fiber To The Home :-p

> I don't think the CPE Router discussion is ambiguous. 

Again, a host can be a router. So, without this clarification,
the CPE Router discussion is ambiguous. 

Shin Miyakawa

---

From: [email-masked]
Date: Thu, 03 Jul 2008 12:05:37 -0600

> "Prefix Delegated service for a routed CPE".
There is no Nat in IPv6. See RFC4864 -  Local Network Protection for IPv6 
for more details.

---

From: [email-masked]
Date: Thu, 03 Jul 2008 12:03:15 -0600

> with DSMIPv6, MNAT-PT etc. for the devices in LAN and RFC1918 space. 
It is good that you are not looking for IPv6NAT does not exist as discussed 
in RFC4864 -  Local Network Protection for IPv6.

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 3 Jul 2008 21:52:10 +0300

> There is no Nat in IPv6. See RFC4864 -  Local Network Protection for IPv6

I think Shin-san's point is that if PD delegation does not work 
uniformly/satisfactorily enough, CPE vendors and ISPs will deploy IPv6 NATs 
rather than tell their customer "sorry you cannot access the Internet with 
more than one computer at a time".

Whether that's a red herring, I will not debate here and now.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Jul 2008 21:31:04 +0200 (CEST)

> Or, how about any applications on the CPE router ?

So, my vision of "CPE" is the same as the authors of the draft that 
started the discussion, a "CPE router". These are for me the same. A host 
is not a router (difference is that a router does IP forwarding, a host 
does not).

> Access Concentorator <----- PPP or whatever upstream link -----> A CPE 
> that is "Something that is involved in the delivery of a service"
>

Yes, and I think these need two different services.

> So, why you exclude this case from (v6)CPE ?

Because I don't want that model going forward, because I don't think 
that's going to be what the customer want.

> If so, I think that people will purchase "one IPv6 global address 
> service for a host" and USE V6NAT to connect any device in their home 
> network, because probably this service will be less expensive than 
> "Prefix Delegated service for a routed CPE". That's too bad.

Why would this be less expensive? I uses the same amount of ISP resources 
and could very well be less complicated for the ISP to deploy? There is no 
technical reason for it to be more expensive.

> "The customer will have to decide this at the time of purchase of the service."

Well, I don't like the idea of end users connecting IPv6 only hosts 
directly to the ISP network, I want the customer to be required to have a 
router, and I don't want the customer to have the possibility to source 
packets in core IP space, and I don't want ISP routers to have IPs in the 
customer IP range.

Personally, I want IPv6 native service to require the customer to have a 
CPE router, if they don't want that, then they can get IPv6 tunneled over 
6to4, PPPoE, L2TP or alike, terminated at their computer.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 3 Jul 2008 15:39:23 -0400

Personally I and Wes both dislike using NAT for IPv6 since IPv6 doesn't call for it. We will have to leave it to the Service Provider(s)(SP) to comment on the cost model. Personally I prefer the SP dole out a PD. The PD doling out from SP may have a hiccup or two depending upon who you talk to at IETF but in general the deployment is expected to work. We have personally tested such PD delegation to a embedded router in a cable modem where the router modem was given a PD from DHCPv6 server that lies in SP domain. This was some quick code we developed. The modem obtained an IA_NA for its cable interface and obtained a IA_PD for it's LAN interface. Then the PD was sub-delegated to SLAAC hosts behind the modem. RIPv6 was used between the modem and cable aggregator to inject routes from modem to the CMTS aggregator. We also tested IPv6 multicast clients in such a deployment.

Anyhow, indeed, even we do not want to debate such issues of one address vs. PD, or things like if a PC needs to be given an IA_PD or not. Our job is to produce a good document that works for, at least, both cable and DSL, and then any network like FIOS. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Denis-Courmont
Sent: Thursday, July 03, 2008 2:52 PM
To: [email-masked]
Cc: Shin Miyakawa; [email-masked]
Subject: Re: new draft on IPv6 CPE router available for review

Le jeudi 3 juillet 2008 21:05:37 [email-masked], vous avez écrit :
> > service for a host" and USE V6NAT to connect any device in their 
> > home network, because probably this service will be less expensive 
> > than "Prefix Delegated service for a routed CPE".
> > That's too bad.
>
> There is no Nat in IPv6. See RFC4864 -  Local Network Protection for 
> IPv6 for more details.

I think Shin-san's point is that if PD delegation does not work uniformly/satisfactorily enough, CPE vendors and ISPs will deploy IPv6 NATs rather than tell their customer "sorry you cannot access the Internet with more than one computer at a time".

--
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Ralph Droms <[email-masked]>
Date: Thu, 3 Jul 2008 15:54:54 -0400

I think Shin is describing not so much a technical problem as an SP  
business model problem.  If SPs decide to continue the IPv4 practice  
of charging by address, subscribers will, naturally, buy one address  
and use NAT.  If SPs use a business model based on IETF  
recommendations and provide a prefix (shorter than /64) as basic  
service (perhaps with variable pricing based on length of prefix?),  
there won't be any motivation for NAT.

- Ralph

On Jul 3, 2008, at Jul 3, 2008,3:39 PM, Hemant Singh (shemant) wrote:

> Personally I and Wes both dislike using NAT for IPv6 since IPv6  
> doesn't call for it. We will have to leave it to the Service  
> Provider(s)(SP) to comment on the cost model. Personally I prefer  
> the SP dole out a PD. The PD doling out from SP may have a hiccup or  
> two depending upon who you talk to at IETF but in general the  
> deployment is expected to work. We have personally tested such PD  
> delegation to a embedded router in a cable modem where the router  
> modem was given a PD from DHCPv6 server that lies in SP domain. This  
> was some quick code we developed. The modem obtained an IA_NA for  
> its cable interface and obtained a IA_PD for it's LAN interface.  
> Then the PD was sub-delegated to SLAAC hosts behind the modem. RIPv6  
> was used between the modem and cable aggregator to inject routes  
> from modem to the CMTS aggregator. We also tested IPv6 multicast  
> clients in such a deployment.
>
> Anyhow, indeed, even we do not want to debate such issues of one  
> address vs. PD, or things like if a PC needs to be given an IA_PD or  
> not. Our job is to produce a good document that works for, at least,  
> both cable and DSL, and then any network like FIOS.
>
> Hemant
>
> uniformly/satisfactorily enough, CPE vendors and ISPs will deploy  
> IPv6 NATs rather than tell their customer "sorry you cannot access  
> the Internet with more than one computer at a time".
>

---

From: David Conrad <[email-masked]>
Date: Thu, 3 Jul 2008 13:45:45 -0700

> there won't be any motivation for NAT.

Provider independence.

Regards,
-drc

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 04 Jul 2008 10:25:37 +0900 (JST)

> There is no Nat in IPv6. See RFC4864 -  Local Network Protection for IPv6 

Eric, I know it. 
I just point out that some GLACELESS person can easily implement 
an IPv6 version of NAT to do something even it is prohibited in RFC.
Of course, I also do not like this. 

So, as many people said to this mailing list
I'd like to recommend to all the ISP to do prefix delegation to the customer.
Again, that is the original motivation of mine
when I wrote requirement for prefix delegation (RFC3769).

At the sametime, even somebody does not like it, because RFC3484 is standard NOW,
so I admit to say that any application on one router CPE is still recommeded to
select its source address from addresses assigned to the WAN i/f.

Especially, Mikael, how do you fix it ? This is still you have not answer yet.

OK. Let me clarify what I want to say.

I am recommending that following (A)+(B) as the way we go
to allow all the implementation which is compatible with today's standard set
can be compatible with the service.

(A)A global IPv6 address is recommened to assign the WAN i/f to a CPE router or a
host that terminates upstream link
(B)Prefixes should be delegated by DHCPv6 to (especially) a CPE router

Even if some ISP does not do assign global IPv6 address to the CPE, 
that's up to that ISP. 
But their customer should be noticed that some machine which is compatible
IPv6 standard specification can not work correctly if that terminates upsteam link.

Again, so I like the following original text of draft-wbeebee-ipv6-cpe-router-00.txt 

-------------------------------------------------------------------------------------
5.3.  Acquire IPv6 address and other configuration parameters

   The CPE Router must process RAs received on the WAN interface and as
   instructed by the RA message, acquire global IPv6 address for WAN
   interface using SLAAC or DHCPv6.  
-------------------------------------------------------------------------------------

Best wishes,

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 04 Jul 2008 10:52:23 +0900 (JST)

Mikael,

> that's going to be what the customer want.

fmmm... 
Please note that I also do not like this and I do not recommend this model,
but actually, at least in Japan, there are millions customer doing this today.
Just because a bridged CPE is cheaper than a router CPE.

We should swtich even those people to be v6 ready 
with less cost (no need to replace their CPE) 
to deploy IPv6 faster and step-by-step.

> directly to the ISP network, 

and you do not like the sensor network..... I understand.....

Shin Miyakawa

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 06:26:33 +0200 (CEST)

> Just because a bridged CPE is cheaper than a router CPE.

In my market, almost everybody has a router CPE, if they have a CPE at all 
(in the ETTH with copper case, people often do not have a CPE at all, and 
if they do, it's a NAT box). I don't see the price difference of 
routed/bridged CPEs at all here.

> We should swtich even those people to be v6 ready with less cost (no 
> need to replace their CPE) to deploy IPv6 faster and step-by-step.

As stated, they can use a tunneled approach if they don't want to do it 
"for real".

> and you do not like the sensor network..... I understand.....

Please elaborate. I don't understand why you're saying that I don't 
like sensor networks because I want a routed CPE.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 06:40:58 +0200 (CEST)

> Especially, Mikael, how do you fix it ? This is still you have not answer yet.

I don't write RFCs. I don't really read them a lot either, just when I 
absolutely need to. On the other hand, I know a lot about router 
architecture and network operational issues and I know what I think would 
be the best operational situation to have for IPv6 in 10 years, and that's 
why I'm advocating the solution I'm advocating.

If you want to remove the merit of my proposal on the basis that I haven't 
supplied RFC quality text to support it, well, then the IETF process is 
broken because it doesn't listen to what the operational community has to 
say. I am supplying operational input here, not RFC proposals.

> Even if some ISP does not do assign global IPv6 address to the CPE,

If the draft doesn't put a strong emphesis on the POSSIBILITY of not 
assigning a WAN IP address (and how this case should be handled), most 
vendors will not implement it.

> IPv6 standard specification can not work correctly if that terminates upsteam link.

I have no problem with that. Services always has restrictions and 
specifications.

> Again, so I like the following original text of draft-wbeebee-ipv6-cpe-router-00.txt

I have no problem with this, apart from that it doesn't say what should be 
done if there is no WAN address received.

I am not saying your solution shouldn't be done, I'm saying I want the 
possibility of both, and if these aren't included in material like this 
draft, my proposal won't be realistically possible anytime soon.

---

From: <[email-masked]>
Date: Fri, 4 Jul 2008 09:32:54 +0300

Hi,

>So, my vision of "CPE" is the same as the authors of the draft 
>that started the discussion, a "CPE router". These are for me 
>the same. A host is not a router (difference is that a router 
>does IP forwarding, a host does not).

If the forwarding is the key differentiator, then isn't e.g. "host"
computers running Microsoft Windows, Apple OS/X, and even certain mobile
phones, also "routers" as they support "sharing of the network
connection", which means forwarding packets from the uplink connection
to local area network - possibly implementing DHCPv4 server, to allocate
private IPv4 addresses for LAN, and NAT for address translation between
LAN and uplink connection?

If the "CPE router" would be defined as something that implements and
executes routing protocols, has MIBs, is fully controllable by ISP then
these hosts would not fit into that category. 

Anyhow, in my mind a "host" is not so much of a name for a category of
devices, but rather a behavioral pattern of a node. At any given moment
a node can start to behave as a "router" (if that is defined only as
doing packet forwarding). For a network the node may still look like a
"host", if the node does this transparently for the network (i.e. with
help of NAT). 

>> This CPE may be a router or a host. there is no difference 
>between two 
>> of those from ISP point of view.
>
....
>Well, I don't like the idea of end users connecting IPv6 only 
>hosts directly to the ISP network, I want the customer to be 
>required to have a router, and I don't want the customer to 
>have the possibility to source packets in core IP space, and I 
>don't want ISP routers to have IPs in the customer IP range.

I did not think that was the idea either? If the end hosts would use
DHCPv6 PD, would that be an act of sourcing packets to IP core? If so,
could the delegating DHCPv6 server locate somewhere where "hosts" could
safely (from ISP point of view) talk?

The talking to ISP core is one differentiator, then we might(?) have:

(1) CPE router:
- allowed to directly source packets to ISP core
[host]---[CPE router]---[ISP]---[Internet]

(2) "Host router":
- not able to directly source packets to ISP core, but still able to
forward packets and use DHCPv6 PD
[host]---[host router]---[CPE router/access
concentrator]---[ISP]---[Internet]

The (1) case is what you are aiming I believe, and the (2) is what I'm
trying to describe.

An example of case (1) would be a DSL box at home/small office, and an
example of case (2) would be a cellular device that:
- connects with point-to-point link to operator's access concentrator
(e.g. GGSN), and gets a /64 prefix for itself (SLAAC)
- uses DHCPv6 PD to get more prefixes, and announces these prefixes to
LAN
- possibly implements DHCPv6 relay in order to enable other devices in
LAN to utilize DHCPv6 PD as well

Best regards,

	Teemu

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 09:07:10 +0200 (CEST)

Correct.

> these hosts would not fit into that category.

For me, for instance a D-link 604 (NAT gateway) is a CPE router, if that 
helps. It doesn't do SNMP, no routing protocols, but some of those are 
provisionable via DHCP (will tftp download conf files).

> "host", if the node does this transparently for the network (i.e. with

Yes, I realise this, but I want my native IPv6 service offering to require 
a "router" class device, even if it means that this "router" only forwards 
traffic logically between the WAN link-local interface and it's internal 
loopback address (DHCPv6-PD assigned space).

> The talking to ISP core is one differentiator, then we might(?) have:

Hm, the problem is that i don't want customers in core IP space, and I 
don't want core in customer IP space.

> [host]---[CPE router]---[ISP]---[Internet]

What adresses would be used between CPE router and ISP? I would like it to 
be link-local only.

> The (1) case is what you are aiming I believe, and the (2) is what I'm

Sounds about right, if (1) CPE-router <-> ISP is link-local.

> LAN to utilize DHCPv6 PD as well

Yes, that sounds about right, but what adress space is used on the p-t-p 
link? Is that the /64? That would mean that the GGSN IP adress in this 
space is globally reachable, with the security implications that brings.

Then again, I think tunneled approach is suboptimal as well, it usually 
involves CPU/network processors which have fairly low performance 
(compared to simple L3 switch devices using ASICs), so they can probably 
get into trouble even if the customer space is DDOSed anyway, and have to 
incorporate means to protect against that.

A cheap and efficient service delivery or IPv6 for me is:

[host]-PD-[CPE router]-ll-[L3 switch]-core

The L2 and L3 device might be the same device, ie a L2/L3 switch with IPv6 
capability, with either VDSL2 or Ethernet PHY. It will most likely have 
limited TCAM space (might be 1024 entries or something like that), does 
forwarding using ASICs and very limited CPU resources, thus the reason why 
I want to protect it from IP packets from the global Internet.

---

From: "Bonness, Olaf" <[email-masked]>
Date: Fri, 4 Jul 2008 09:22:45 +0200

> Because I don't want that model going forward, because I don't think that's going to be what the customer want.

You might not like this model but it's still reality and not clear until when it will vanish.

> Well, I don't like the idea of end users connecting IPv6 only hosts directly to the ISP network, I want the customer to be required to have a router, and I don't want the customer to have the possibility to source packets in core IP space, and I don't want ISP routers to have IPs in the customer IP range.

Look above. Who will force the customers to buy a new DSL-box or CPE? Nobody can.

Agree regarding "ISP routers to have IPs in the customer IP range."

Cu Olaf

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 09:51:21 +0200 (CEST)

> You might not like this model but it's still reality and not clear until 

I don't want it to vanish, but I do want devices that support my model. I 
am not trying to make the standard model today (RA) to go away, but I want 
to be able to design a service per what I have written before, and that 
there are devices in the market that support it.

> Look above. Who will force the customers to buy a new DSL-box or CPE? 

For new deployments it should be ok. I'd say CPE routers are often churned 
out over 3-5 years.

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 04 Jul 2008 17:46:45 +0900 (JST)

Mikael,

> say. I am supplying operational input here, not RFC proposals.

No, no. at least, as I said, I think your input is quite important and usuful.

But at the same time, please do not think that you're the ONLY person
supplying operational input here.

Please be noticed that we NTT is also one of ISPs have a lot of 
operational experiences for IPv6(and of course IPv4), has already 
deploying commercial IPv6 services at huge scale 
and I am supplying operational input here from our real operation and RFC proposals.
                                                                  ===
Also please do not disparage IETF activities and 
Please have respect for the standardization.
If you just say what you want and ask somebody else to modify the text
so that it should be compatible with YOUR opinion, I don't think that's fair.

> done if there is no WAN address received.

Fmm.. sounds strange.. because according the above text, the CPE Router must 
acquire global IPv6 address for WAN interface using SLAAC or DHCPv6.
There is no possiblity to have no WAN address received, isn't it ?

> possibility of both, 

I see. OK Then, how about like this ? (This is actually just an idea. I think
that Wes and Hemant are able to write better text than mine...)

    The CPE can acquire global IPv6 address for WAN interface using SLAAC or DHCPv6. 
    In this case, The CPE can be anything, a router CPE, a host, strong host model or
    week host model, following RFC3484 recommendation or even not.
    If operator that the CPE is going to connect, does not assign 
    any global IPv6 address for WAN interface, there is a limitation on CPE 
    architecture so that source address on it should be selected from 
    PDed address which is not recommended in RFC3484.

Best wishes,

Shin Miyakawa

---

From: [email-masked]
Date: Fri, 04 Jul 2008 04:00:27 -0600

> 6to4, PPPoE, L2TP or alike, terminated at their computer. 
This model will not work in the Cellular or Mobile worlds where the end 
device is a phone or mini internet device (MID). These will connect directly 
to the radio switch and will be aggregated into the network there. 

In the case of WiMAX or HSPDA this could be any of the next generation (out 
in this quarter) Intel ATOM, GTC, Nvidia, or other chip set based portable 
devices. These will be able to connect to WiMAX or GSM, EVDO, 3G, etc. 
network directly. So they will be (by definition) routers as well as end 
user devices. 

If the intention for the scope of this document discounts these devices 
(which currently out number desk top PCs almost 2 to 1) then the document is 
of too narrow a scope.
Eric

---

From: [email-masked]
Date: Fri, 04 Jul 2008 04:03:26 -0600

Ralph Droms writes: 

> business model problem.  If SPs decide to continue the IPv4 practice  of 
> charging by address, subscribers will, naturally, buy one address  and use 
> NAT.  If SPs use a business model based on IETF  recommendations and 
> provide a prefix (shorter than /64) as basic  service (perhaps with 
> variable pricing based on length of prefix?),  there won't be any 
> motivation for NAT. 
> 
Ralph,
If this business model happens then I expect to see some sort of extension 
of the IPv4 NAT models with v6 prefixes, and this will lead to breaking the 
net worse than NAT (and multiple nested NATs) do today.
Eric

---

From: [email-masked]
Date: Fri, 04 Jul 2008 04:06:05 -0600

>> there won't be any motivation for NAT.
This independence would be as easily served by changing the v6 prefix and 
keeping the /64 addresses the same. This kind of renumbering has been built 
into v6. While keeping the old thinking of NAT kills the end-to-end concept 
of v6 and hurts many applications that needed work arounds in v4 in order to 
work. 

We killed v6NAT once, let's not resurrect it again.

---

From: [email-masked]
Date: Fri, 04 Jul 2008 04:08:58 -0600

> Of course, I also do not like this. 

Yes, but that does not mean that it will work with other applications that 
are RFC compliant. 

> when I wrote requirement for prefix delegation (RFC3769).

This still seems like the best solution. 

> IPv6 standard specification can not work correctly if that terminates upsteam link. 

Agreed

---

From: [email-masked]
Date: Fri, 04 Jul 2008 04:25:39 -0600

> say. I am supplying operational input here, not RFC proposals. 

This is fine, if there is a real need the text can be edited to match 
required format. The real questions are:
 1. Is this really a need?
 2. If so for all IPv6 end devices or just CPE routers that have other   
devices aggregated to them via copper, fiber, wireless?
 3. What about other devices that act as a router but are the actual end-use 
device? Do we ignore them, create a diffrent RFC and then reference it?
 4. Is there a consensus that these are worth the WG taking up and dealing 
with? 

> done if there is no WAN address received.

Can you propose an addition or solution?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 12:45:58 +0200 (CEST)

Of course not.

> Please have respect for the standardization.

I have great respect for the standardization, which is why I'm spending 
hours here trying to influence it.

> so that it should be compatible with YOUR opinion, I don't think that's fair.

Well, I prefer to have a discussion and achieve consensus about what needs 
to be done, before starting to modify documents.

> There is no possiblity to have no WAN address received, isn't it ?

Exactly, which is why I have a problem with it. I want the option of not 
assigning a WAN IPv6 address. I might misunderstand the context here, if 
this is not applicable in this part of the text, then I am sorry and we 
can move on. Does the wording allow for "link-local only for WAN" and 
DHCPv6-PD, or does it need to be changed for this to be ok?

>    PDed address which is not recommended in RFC3484.

This writing is technically correct in aspect to what I want, but the 
writing (at least to me) implies that not following RFC3484 in the "global 
IPv6 WAN address" aspect is a bad idea, which I think is a bit biased.

If you cut out "which is not recommended in RFC3484." then it becomes more 
neutral. The writing in RFC3484 states:

"They do not override choices made by applications or upper-layer 
protocols, nor do they preclude the development of more advanced 
mechanisms for address selection."

So basically, my proposal doesn't violate RFC3484, even though it goes 
against the recommendations in it? I looked thru RFC3484 again just to 
make sure, and my 10 minute reading of it didn't yield anything my 
proposal de facto violates.

I don't really understand why you so strongly oppose my idea? It doesn't 
stop or change any existing functionality, it just brings in requirement 
for new functionality (or not really new, it's rather describes a 
combination of functionalities already present in order to achieve a 
specific operational goal)?

If the ISP highly values to have IP separation of customer IP space and 
ISP IP space, then they can deploy along my proposal, if they don't, well, 
then they can go along the lines of RFC3484 and indeed assign a globally 
routable IPv6 address to the WAN interface of the customer host/router.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 12:52:05 +0200 (CEST)

> devices aggregated to them via copper, fiber, wireless?

My requirement is only for home gateway devices, I don't want to change 
the behaviour of end-hosts. My proposal is also to not remove any 
functionality or limit it, just to add. I am not aware of my proposal 
being in violation of any current wording in any document, but if it is, I 
volunteer to participate in work in getting it fixed.

> device? Do we ignore them, create a diffrent RFC and then reference it?

I would say this is still a router, and it needs to choose a globally 
reachable PD-IP (either a LAN interface or a loopback interface) to use 
for communication with the outside world.

> 4. Is there a consensus that these are worth the WG taking up and dealing 

I believe there are at least two people who have chimed in saying that 
they think this is a good idea, plus the authors of the draft also stated 
that they were willing to bring in wording to allow for it.

---

From: [email-masked]
Date: Fri, 04 Jul 2008 04:51:12 -0600

> loopback address (DHCPv6-PD assigned space).

Then I suspect you will be greatly disappointed as I do not see most of the 
devices that will be using IPv6 in the future fitting into this category. 
Cellular devices outnumber PCs today, and unless you plan to stretch the 
definition of CPE Router to include the ones at cell sites then you will 
find that more devices are not behind a CPE router than those that are. Look 
at the past 5 year trend to mobile internet (Cellular, WiMAX, etc.), RFIDs, 
Automotive and traffic systems, etc. These devices do not see a device that 
would fit into this document even though they eventually are served by a 
router. 

>> The talking to ISP core is one differentiator, then we might(?) have:

I suggest that you try thinking of IPv6 as being used by non-ISP service 
providers, this may help with the differences we are discussing. 

> don't want core in customer IP space. 

This is the old telco model, where there was a mandated telco owned CPE 
acting as a termination device. Cellular started the decline of this model 
as did ISDN modems inside of computers. It worked when cellular used very 
little data, but with devices moving to VoIP and full data applications 
there will be routing and other activities down to the end user device. 

I doubt that we will go back to it. 

Even today you have this where WiFi on laptops serve additional devices 
acting as a hot spot (router) for them. 

> I want to protect it from IP packets from the global Internet.

I am sorry, these devices are like children, we have to let them out into 
the world unprotected. ;) 

Eric

---

From: [email-masked]
Date: Fri, 04 Jul 2008 05:00:10 -0600

Mikael Abrahamsson writes: 

>> 3. What about other devices that act as a router but are the actual 
>> end-use device? Do we ignore them, create a diffrent RFC and then 
>> reference it?
> 
It sounds to me like there is some agreement that there is something here in 
need of defining/clarifying. 

I agree this would be good for the WG to work on towards a consensus 
provided we expand the scope a little to cover the rest of the situations 
where routing functions are required. 

Eric

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2008 13:02:06 +0200 (CEST)

On Fri, 4 Jul 2008, [email-masked] wrote:

> definition of CPE Router to include the ones at cell sites then you will find 
> that more devices are not behind a CPE router than those that are. Look at 
> the past 5 year trend to mobile internet (Cellular, WiMAX, etc.), RFIDs, 

I have no problem broadening the scope of the document even further. I 
know very little of the mobile technologies you mention.

> acting as a termination device. Cellular started the decline of this model as

In my market, for residential CPE routers, the telco doesn't own or manage 
the device to a large extent. Here, ISPs send out a list of "recommended 
CPEs" to use with the service, for which the ISP will be able to offer 
support/help in case of problems. If the customer runs into problems and 
has purchased other devices, the ISP will not be able to help with CPE 
router related problems.

Some ISPs bundle a device when you purchase the service, as the cost of 
the CPE is quite low in comparison to other aspects of the turn-up 
process, but it's still managed by the customer (but comes with sensible 
defaults).

---

From: <[email-masked]>
Date: Fri, 4 Jul 2008 16:06:09 +0300

Hi,

>Yes, I realise this, but I want my native IPv6 service 
>offering to require a "router" class device, even if it means 
>that this "router" only forwards traffic logically between the 
>WAN link-local interface and it's internal loopback address 
>(DHCPv6-PD assigned space).

There definitely are different use-cases with different requirements. 

You mentioned elsewhere that the scope of the document could be
expanded. What do the authors think about that? Should we sit down in
Dublin to discuss?

>> (1) CPE router:
>> - allowed to directly source packets to ISP core [host]---[CPE 
>> router]---[ISP]---[Internet]
>
>What adresses would be used between CPE router and ISP? I 
>would like it to be link-local only.

No comment for this (I would need to study more on what issues
link-local only could bring, but I trust others here are more
knowledgeable).

>Yes, that sounds about right, but what adress space is used on 
>the p-t-p link? Is that the /64? That would mean that the GGSN 
>IP adress in this space is globally reachable, with the 
>security implications that brings.

Yes, /64, which is per mobile allocated by the network as the mobile
usually acts as a host and needs a global address (it may implement
RFC4941 as well). The mobile node itself is well positioned to attack
GGSN, as by its nature it is on the same link with it, thus GGSN has to
prepare well for attacks on its subscriber-facing interfaces (probably
has all but necessary ports closed). For the attacks from the Internet,
there is a firewall between GGSN and Internet. 

I'm not sure if the GGSN even configures itself global address from the
prefixes it gives to subscribers (does router have to configure an
address for itself from the prefixes it sends out in RAs?). I was unable
to verify this right now.

Best regards,

	Teemu

---

From: David Conrad <[email-masked]>
Date: Fri, 4 Jul 2008 08:37:55 -0700

I do not wish to resurrect the anti-NAT wars, so this will be my last  
comment on this thread.

On Jul 4, 2008, at 3:06 AM, [email-masked] wrote:
> This independence would be as easily served by changing the v6  
> prefix and keeping the /64 addresses the same. This kind of  
> renumbering has been built into v6.

Not really.  Ask any non-trivial enterprise network operator or simply  
look at the rationales for the push at _all_ the RIRs for provider  
independent IPv6 allocation policies.  IPv6 may make renumbering  
somewhat easier than IPv4, but it does not solve the issue.  Filters,  
firewalls, network management systems, domain name servers,  
registries, and registrars are all just some of the places in which  
IPv6 literal addresses will get transcribed and have to be changed in  
the face of a prefix renumbering event.  Because renumbering IPv6  
prefixes will not be transparent, there will be a market for NATv6.   
The only question is whether the downsides of NATv6 will be sufficient  
to deter its use.  Since people have been trained to accept NATv4, I  
am somewhat skeptical the vast majority of users will rebel against  
NATv6.

Regards,
-drc

---

From: Shin Miyakawa <[email-masked]>
Date: Sat, 05 Jul 2008 00:52:03 +0900 (JST)

From: <[email-masked]>
Subject: RE: new draft on IPv6 CPE router available for review
Date: Fri, 4 Jul 2008 16:06:09 +0300
> Should we sit down in Dublin to discuss?

This is very nice idea, and let us have good Irish beer there together :-)

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Sat, 05 Jul 2008 00:51:50 +0900 (JST)

Mikael,

I see. Then, next time, please refrain from using a bit offensive words such as

> say. 

This sounds that YOU ARE the operational community ITSELF.
But now I understand, it is not what you meant, but please understand it sounds

.......

> assigning a WAN IPv6 address. 

OK. You want the OPTION now. Sounds very nice.

> This writing is technically correct in aspect to what I want

Very Good. I really appreciate that we are coming closer to achieve a consensus.

> but the writing (at least to me) implies that not following RFC3484 in the "global 

fmmm.. I see..

Of course, it still seems to me that RFC3484 recommends to select address
from the addresses which are assigned to the WAN I/F.
and some existing implementation (such as MS Vista) do this so...

> neutral. 

But, if you think this is a matter of controversial, it is OK for me to cut out
"which is not recommended in RFC3484"  from above text. Let us do so.

> I don't really understand why you so strongly oppose my idea? 
Of course, I did not really understand why you so strongly opposed my idea too :-p
             ===                                                ==

OK.

If your idea is allowing the link-local only model is an option, then fine for me.
                                                      =========
If your idea is the link-local only model is the only choice, then I oppose it.

Please understand that I "prefered" (and actually still prefer) your idea originally, 
Otherwise we did not write RFC4241 that contains following text

----------- from RFC4241 --------------
>2.4. Address Assignment
<snip>
>   Because a link-local address is already assigned to the CPE's
>   upstream interface, global-scope address assignment for that
>   interface is optional.
----------- from RFC4241 --------------

But now, because I think that we should allow all the implementation
which is compatible with today's standard set can be compatible with the service
(This's the STANDARDIZATION, isn't it ?),
the SERVICE should be ready to assign global IPv6 address for WAN interface of the CPE.

> ISP IP space, then they can deploy along my proposal,

maybe. or maybe not.

But if the ISP highly values to allow any implementation which is compatible 
with IPv6 standard set to be used by its customers, 
then they will not deploy along your proposal.

Best wishes,

Shin Miyakawa

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 5 Jul 2008 11:53:34 +0200 (CEST)

> OK. You want the OPTION now. Sounds very nice.

Yes, that was my intention all along, sorry for my inability to 
communicate this.

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Sat, 5 Jul 2008 05:18:25 -0700 (PDT)

--- On Wed, 7/2/08, Francois-Xavier Le Bail <[email-masked]> wrote:

> The CPE must also support IPv4, and for using one subnet in
> IPv4 world, it's a practice to have a LAN bridge with
> Ethernet, Wifi, etc. interfaces adding to it.

When the CPE router has only a link-local address on the WAN port,
if the CPE has a LAN bridge, I hope there is an option to have the 
global-scope address set on the LAN bridge (from IA_PD via DHCPv6)
as an alternative to loopback solution.

Do you agree ?

Best Regards,

Francois-Xavier

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 6 Jul 2008 08:14:10 -0400

If the Service Provider has doled out an IA_PD option, then the CPE
Router always has the option to use a set of IPv6 address(es) from the
IA_PD to configure on the LAN interface(s) of the CPE Router.

Hemant

-----Original Message-----
From: Francois-Xavier Le Bail [mailto:[email-masked]] 
Sent: Saturday, July 05, 2008 8:18 AM
To: Wes Beebee (wbeebee); Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: new draft on IPv6 CPE router available for review

--- On Wed, 7/2/08, Francois-Xavier Le Bail <[email-masked]> wrote:

> IPv4 world, it's a practice to have a LAN bridge with Ethernet, Wifi, 
> etc. interfaces adding to it.

When the CPE router has only a link-local address on the WAN port, if
the CPE has a LAN bridge, I hope there is an option to have the
global-scope address set on the LAN bridge (from IA_PD via DHCPv6) as an
alternative to loopback solution.

Do you agree ?

Best Regards,

Francois-Xavier

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Sun, 6 Jul 2008 09:41:26 -0700 (PDT)

You're right.

I must explain more clearly my proposal.

For the model where WAN interface only acquires a link-local address,
I see two options for the interface which will be assigned a global IPv6
address sub-delegated from IA_PD via DHCPv6 :

- If there is a logical LAN bridge, which is always up even if the LAN 
interfaces attached to it are individualy down, CPE will use the bridge 
which will be assigned such a global IPv6 address.
These is no need to add a loopback interface.

- Else the CPE router will use a Loopback interface which will be assigned such a global IPv6 address.

Francois-Xavier

--- On Sun, 7/6/08, Hemant Singh (shemant) <[email-masked]> wrote:

> From: Hemant Singh (shemant) <[email-masked]>
> To: "Francois-Xavier Le Bail" <[email-masked]>, "Wes Beebee (wbeebee)" <[email-masked]>
> Cc: [email-masked]
> Date: Sunday, July 6, 2008, 8:14 AM
> > And this bridge is always up, even if the LAN
> interfaces are 
> > individualy down.
> > So binding the global-scope management address to this
> LAN bridge can 
> > be a way to consider.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 6 Jul 2008 20:19:37 -0400

Folks,

Thanks for everyone's proposals and ideas, but we are not seriously
looking at ideas from individual folks - it's not proving to be very
productive. If you are a DSL or FIOS person, please send your proposals
to David Miles who can collate all proposals and he will also work with
Mark Townsley who works on DSL. We are working with David Miles and have
already incorporated his requests from DSL folks in our next version of
the draft. We don't need any proposals or ideas for cable industry since
we have that covered ourselves. 

Any other industry will be dealt by us on a case by case basis.

Thanks.

Hemant

-----Original Message-----
From: Francois-Xavier Le Bail [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 12:41 PM
To: Wes Beebee (wbeebee); Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: new draft on IPv6 CPE router available for review

You're right.

For the model where WAN interface only acquires a link-local address, I
see two options for the interface which will be assigned a global IPv6
address sub-delegated from IA_PD via DHCPv6 :

- Else the CPE router will use a Loopback interface which will be
assigned such a global IPv6 address.

Francois-Xavier

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 7 Jul 2008 12:10:03 -0400

I'm sorry -- I just subscribed to this group last week (at the
suggestion of David Miles and Mark Townsley). Can you please explain
what you're saying here? I don't want to misinterpret what you're saying
-- but to me it sounds as if you're asking DSL and FIOS access providers
to not participate in the discussions on this list, or to provide
feedback directly to the list? That we are only "permitted" to provide
input via David or Mark? Since that's a very un-IETF way of doing things
(where generally all individual opinions are welcome, independent of
what company they work for), I want to be sure I didn't misunderstand.

I was about to comment on some of the items discussed in this thread,
but wanted to be sure, first, that I understood this particular email
about who was "welcome" to participate. I thought that Mark and David
were providing an interface for providers and operators not comfortable
with direct participation on IETF lists, and not that we were somehow
"required" to go through them to have our opinions heard.

Thanks,
Barbara

Barbara Stark
AT&T

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Sunday, July 06, 2008 8:20 PM
To: Francois-Xavier Le Bail; Wes Beebee (wbeebee)
Cc: [email-masked]; MILES DAVID; Mark Townsley (townsley)
Subject: RE: new draft on IPv6 CPE router available for review

Folks,

Thanks.

Hemant

-----Original Message-----
From: Francois-Xavier Le Bail [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 12:41 PM
To: Wes Beebee (wbeebee); Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: new draft on IPv6 CPE router available for review

You're right.

Francois-Xavier

> alternative to loopback solution.

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 7 Jul 2008 12:57:43 -0400

Mark,

Sounds fine. I do apologize for anointing you and David on this work on
the fly. I thought since I saw David's email to the DSL Forum saying
he'd work with us from DSL land to give us firm requirements, I
mentioned David's name. Then knowing you work to liaise IETF and DSL,
you may be another good candidate. I also sent this email because quite
a few emails on our draft were not productive for us or that new folks
had not read the earlier comments from us or others. That is why I
thought if other folks are from DSL land, they could all get together
and give us one stock requirement. 

Anyhow, seeing where the winds are blowing now, moving forward, I and
Wes can handle all the requests including understanding ourselves what
the DSL requirements are. 

I will reply to Barbara's email shortly.

Hemant

-----Original Message-----
From: Mark Townsley (townsley) 
Sent: Monday, July 07, 2008 12:44 PM
To: Stark, Barbara
Cc: Hemant Singh (shemant); Francois-Xavier Le Bail; Wes Beebee
(wbeebee); [email-masked]; MILES DAVID
Subject: Re: new draft on IPv6 CPE router available for review

Barbara, please feel free to discuss IPv6 issues on this list freely. I
can only imagine that Hemant feels a bit overloaded with comments from a
number of places since the introduction of his draft document (which is
a good indicator that there is a lot of pent-up desire for work around
this topic). Note that his document is an individual submission at this
stage, not a product of the WG. If Hemant needs to step back a little,
that's OK, there are plenty of other people on this list with something
to say.

Hemant, I don't think David or I should be anointed as the central
source for collecting input on DSL requirements for a future v6ops
document. At some point, if v6ops creates a WG document on IPv6 CPE/RG
requirements, the editor(s) of that document will be responsible for
ensuring that WG consensus, achieved on this list, is recorded properly.

So, that means discussion happens on the list and the editors are only
recording what the WG ultimately wants to express, not the other way
around.

In the end, there might be a diversion between the RG requirements for
Cable vs. DSL vs. FTTH, etc, but I would hope these to be as congruent
and complimentary as possible - at least for all of the "fixed wire"
cases.

- Mark

Stark, Barbara wrote:
> -- but to me it sounds as if you're asking DSL and FIOS access 
> providers to not participate in the discussions on this list, or to 
> provide feedback directly to the list? That we are only "permitted" to

> provide input via David or Mark? Since that's a very un-IETF way of 
> doing things (where generally all individual opinions are welcome, 
> independent of what company they work for), I want to be sure I didn't
misunderstand.
> were providing an interface for providers and operators not 
> comfortable with direct participation on IETF lists, and not that we 
> were somehow "required" to go through them to have our opinions heard.
>
> Thanks,
> Barbara
>
> Barbara Stark
> AT&T
>
> productive. If you are a DSL or FIOS person, please send your 
> proposals to David Miles who can collate all proposals and he will 
> also work with Mark Townsley who works on DSL. We are working with 
> David Miles and have already incorporated his requests from DSL folks 
> in our next version of the draft. We don't need any proposals or ideas

> for cable industry since we have that covered ourselves.
>
> I see two options for the interface which will be assigned a global 
> IPv6 address sub-delegated from IA_PD via DHCPv6 :
>

> interfaces attached to it are individualy down, CPE will use the 
> bridge which will be assigned such a global IPv6 address.
>>> The CPE must also support IPv4, and for using one
>>>       
>> subnet in
>>     
>>> IPv4 world, it's a practice to have a LAN bridge
>>>       
>> with Ethernet, Wifi,
>>     

> The information transmitted is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary, 
> and/or privileged material. Any review, retransmission, dissemination 
> or other use of, or taking of any action in reliance upon this 
> information by persons or entities other than the intended recipient 
> is prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. GA625
>
>
>
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 7 Jul 2008 14:01:47 -0400

Barbara,

I (Hemant) already replied to Mark's email and explained why I sent my
email over the weekend. I have no problem with anyone stepping in and
commenting - I was mistaken in thinking that we'd work with David Miles
as one single contact from DSL folks. We, especially, welcome feedback
from Service Provider (SP) operators since it is their network that gets
affected by such a device.

We published a new version of the draft today. This version caters to
two big requests that came to us since posting of the -00 version. The
requests were (a) to support only a link-local address on the WAN
interface, and (b) to support a LAN up first before WAN behavior of the
CPE Router. Please see Change Log for new version of the draft.

http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.txt

Regards.

Hemant & Wes

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 12:10 PM
To: Hemant Singh (shemant); Francois-Xavier Le Bail; Wes Beebee
(wbeebee)

Thanks,
Barbara

Barbara Stark
AT&T

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

Folks,

Thanks.

Hemant

-----Original Message-----
From: Francois-Xavier Le Bail [mailto:[email-masked]]
Sent: Sunday, July 06, 2008 12:41 PM
To: Wes Beebee (wbeebee); Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: new draft on IPv6 CPE router available for review

You're right.

Francois-Xavier

      

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA625

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 7 Jul 2008 21:36:02 +0300

> http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01.txt

   Note that if the home does not cascade CPE routers, then ULA's are
   not needed for the LAN interfaces, since link-local addresses are
   sufficient for configuration.  After the WAN interface initializes,
   then the LAN interface(s) can acquire global unicast addresses.

This is simply not true. Most (at least quite many) IPv6 applications are 
incapable of using link-local addresses, owing to the peculiar way the socket 
API deals with them. Namely, it requires that the socket address scope ID be 
set. The only way to have fully operational LAN communications is to keep an 
ULA prefix always, regardless of cascading. And it should preferably remain 
present even if the WAN connection has succeeded, so that:
 - pre-existing connections don't break needlessly when the WAN goes up,
 - boxes can easily check if a host is "outside" or "inside",
 - connections don't break if the delegated prefix changes.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 7 Jul 2008 16:22:49 -0400

Remi,

Please see in line below between "<hs> and </hs>". 

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 2:36 PM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); [email-masked]
Subject: Re: new draft on IPv6 CPE router available for review

This is simply not true. Most (at least quite many) IPv6 applications are incapable of using link-local addresses, owing to the peculiar way the socket API deals with them. Namely, it requires that the socket address scope ID be set. The only way to have fully operational LAN communications is to keep an ULA prefix always, regardless of cascading. And it should preferably remain present even if the WAN connection has succeeded, so that:
 - pre-existing connections don't break needlessly when the WAN goes up,

<hs>
We know a web browser can access the CPE Router on the same IPv6 LAN segment using a link-local address - no denying that. Please tell us what application that uses socket API is needed during manual configuration when the CPE Router is being configured via the web? Or what else needs to be done on the CPE Router besides manual configuration (via web) for which sockets API break because the LAN interface is assigned only a link-local address?

As a side note, we do say in the draft once ULA is configured on the LAN interface(s), the ULA co-exists with GUA (Global Unique Address).  The GUA gets assigned to the LAN interface(s) later when the WAN interface completes acquisition of IA_PD.
</hs>

Hemant & Wes.

--
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 7 Jul 2008 16:40:20 -0400

I just want to reiterate that we are happy to receive any comments that
the WG members may have regarding our draft in the interest of making
the draft better represent the WG consensus.  In the future, we will
make sure that we make frequent and timely updates to the draft so that
we can ensure that the discussion moves in a forward direction.

- Wes 

-----Original Message-----
From: Hemant Singh (shemant) 
Sent: Sunday, July 06, 2008 8:20 PM
To: 'Francois-Xavier Le Bail'; Wes Beebee (wbeebee)
Cc: [email-masked]; MILES DAVID; Mark Townsley (townsley)
Subject: RE: new draft on IPv6 CPE router available for review

Folks,

Thanks.

Hemant

-----Original Message-----
From: Francois-Xavier Le Bail [mailto:[email-masked]]
Sent: Sunday, July 06, 2008 12:41 PM
To: Wes Beebee (wbeebee); Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: new draft on IPv6 CPE router available for review

You're right.

Francois-Xavier

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Mon, 7 Jul 2008 23:44:46 +0300

Le lundi 7 juillet 2008 23:22:49 Hemant Singh (shemant), vous avez écrit :
> incapable of using link-local addresses, owing to the peculiar way the
> socket API deals with them. Namely, it requires that the socket address
> scope ID be set. The only way to have fully operational LAN communications
> is to keep an ULA prefix always, regardless of cascading. And it should
> preferably remain present even if the WAN connection has succeeded, so
> that: - pre-existing connections don't break needlessly when the WAN goes
> up,
>
> <hs>
> We know a web browser can access the CPE Router on the same IPv6 LAN
> segment using a link-local address - no denying that. Please tell us what
> application that uses socket API is needed during manual configuration when
> the CPE Router is being configured via the web? Or what else needs to be
> done on the CPE Router besides manual configuration (via web) for which
> sockets API break because the LAN interface is assigned only a link-local
> address?

I tried two different browsers.

In both of them http://[fe80::211:11ff:fe12:3456]:8080/ resulted in a 
connection failure. I had to type 
http://[fe80::211:11ff:fe12:3456%eth0]:8080/ which violates the HTTP URI 
spec, and requires that I know how my network interface is called.

Also, any protocol that embeds IPv6 addresses will fail, since the scope 
specifier is host-specific such that there is no sane way to convey it across 
the network.

> As a side note, we do say in the draft once ULA is configured on the LAN
> interface(s), the ULA co-exists with GUA (Global Unique Address).  The GUA
> gets assigned to the LAN interface(s) later when the WAN interface
> completes acquisition of IA_PD. </hs>

I am well aware of that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 7 Jul 2008 16:58:11 -0400

Note that while it is possible to use link-locals to configure the CPE Router (when they are not cascaded), it may be inconvenient to do so as you point out.  Therefore, we will remove the following sentence from the draft:

"Note that if the home does not cascade CPE routers, then ULA's are not needed for the LAN interfaces, since link-local addresses are sufficient for configuration."

Thanks,
- Wes and Hemant

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 4:45 PM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); [email-masked]
Subject: Re: new draft on IPv6 CPE router available for review

Le lundi 7 juillet 2008 23:22:49 Hemant Singh (shemant), vous avez écrit :
> > http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-01
> > .t
> > xt
>
> This is simply not true. Most (at least quite many) IPv6 applications 
> are incapable of using link-local addresses, owing to the peculiar way 
> the socket API deals with them. Namely, it requires that the socket 
> address scope ID be set. The only way to have fully operational LAN 
> communications is to keep an ULA prefix always, regardless of 
> cascading. And it should preferably remain present even if the WAN 
> connection has succeeded, so
> that: - pre-existing connections don't break needlessly when the WAN 
> goes up,
>
> <hs>
> segment using a link-local address - no denying that. Please tell us 
> what application that uses socket API is needed during manual 
> configuration when the CPE Router is being configured via the web? Or 
> what else needs to be done on the CPE Router besides manual 
> configuration (via web) for which sockets API break because the LAN 
> interface is assigned only a link-local address?

In both of them http://[fe80::211:11ff:fe12:3456]:8080/ resulted in a connection failure. I had to type http://[fe80::211:11ff:fe12:3456%eth0]:8080/ which violates the HTTP URI spec, and requires that I know how my network interface is called.

Also, any protocol that embeds IPv6 addresses will fail, since the scope specifier is host-specific such that there is no sane way to convey it across the network.

> As a side note, we do say in the draft once ULA is configured on the 
> LAN interface(s), the ULA co-exists with GUA (Global Unique Address).  
> The GUA gets assigned to the LAN interface(s) later when the WAN 
> interface completes acquisition of IA_PD. </hs>

I am well aware of that.

--
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jul 2008 10:26:51 +1200

>> there won't be any motivation for NAT.

For domestic subscribers (i.e. the mass market for
CPE) this simply isn't an issue. Each time they restart
the CPE they will get new addresses via SLAAC; that's no
different than getting new v4 addresses via DHCP.
It's a matter of total indifference whether they get
an RFC1918 address, a public v4 address, or a v6 address,
for the mass market user. As long as it works.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 8 Jul 2008 07:36:31 +0200 (CEST)

Hi,

I am happy with the writing of the first chapter of 5.3.2, but the second 
chapter perhaps needs to be lifted out of 5.3.2 as it refers to text both 
in 5.3.1 and 5.3.2 ? Perhaps the second chapter of 5.3.2 needs to be 
5.3.3? If indeed intended for 5.3.2, perhaps the mention of WAN globally 
routable IP address is a typo?

In 9, would it make sense to also mention other queuing and marking 
mechanisms? I think home users would be very much helped by other queuing 
mechanisms than a few fifo queues? To my home (I use cisco routers) I have 
a fairly advanced set of bandwidth reservation queues and do fair-queue on 
the rest of the traffic, and this helps a lot compared to just fifo in 
each queue. I would love to see this functionality in smaller devices as 
well, as this would most likely help the "I have 24/1 ADSL and when I run 
bittorrent and upload, my download speeds drop)", as a more advanced 
queuing algorithm could prioritize TCP ACK packets (or just small packets 
in general). I believe Linux already has a lot of this, so for a vendor 
using embedded Linux, this would be fairly easy to enable and recommending 
it in the draft might help them in their decision to do so.

Apart from that, I am grateful that you included the unnumbered model as 
an option in the draft. Thanks a lot!

Regards,

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 8 Jul 2008 10:46:54 -0400

Mikael,

What you are referring to as a "chapter", I call it a paragraph. Yes,
indeed, the second paragraph at the end of section 5.3.2 is meant for
both sections 5.3.1 and 5.3.2, but xml formatting makes it look like the
paragraph is for section 5.3.2 only. We'll see what we can do about
that.  

As for section 9, we don't plan to get into suggestions for queuing.
It's left to the CPE Router vendor to do what they want. However, if the
community would like us to add more details to this section for queuing
algorithms, we can add that. But more people have to ask for it.

Thanks.

Hemant

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 1:37 AM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); [email-masked]
Subject: RE: new draft on IPv6 CPE router available for review

Hi,

I am happy with the writing of the first chapter of 5.3.2, but the
second chapter perhaps needs to be lifted out of 5.3.2 as it refers to
text both in 5.3.1 and 5.3.2 ? Perhaps the second chapter of 5.3.2 needs
to be 5.3.3? If indeed intended for 5.3.2, perhaps the mention of WAN
globally routable IP address is a typo?

In 9, would it make sense to also mention other queuing and marking
mechanisms? I think home users would be very much helped by other
queuing mechanisms than a few fifo queues? To my home (I use cisco
routers) I have a fairly advanced set of bandwidth reservation queues
and do fair-queue on the rest of the traffic, and this helps a lot
compared to just fifo in each queue. I would love to see this
functionality in smaller devices as well, as this would most likely help
the "I have 24/1 ADSL and when I run bittorrent and upload, my download
speeds drop)", as a more advanced queuing algorithm could prioritize TCP
ACK packets (or just small packets in general). I believe Linux already
has a lot of this, so for a vendor using embedded Linux, this would be
fairly easy to enable and recommending it in the draft might help them
in their decision to do so.

Regards,

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 8 Jul 2008 14:19:47 -0400

Hi Hemant and Wes,
Thanks for the update of this draft. I think it could potentially be
quite useful to the industry. But, just so you understand my focus, I'm
more interested in how such a work could drive the behavior of retail
"CPE routers", than I am in how it can drive specifications for routers
that service providers (SPs) source and provide to end users. I pretty
much know what I want in a CPE router -- my biggest unknown is how to
interact with retail routers on the LAN-side of my SP CPE router,
because I'm not sure how they'll behave. I also want to try and make
sure that these retail routers can operate, with minimal or no
configuration, without a SP router between them and the SP access
network (where applicable).

With that in mind, here are a few comments.

1. Based on what I'm hearing from the access network side of my company,
I'm expecting for retail CPE routers (in the US) to continue to need to
support two different IP stacks to the WAN: IPv6/PPP/PPPoE/Ethernet and
IPv6/Ethernet. Today (in IPv4 retail routers), this is a configurable
option that defaults to IP/Ethernet. I would expect that to be the
default with IPv6, as well. If a device is configured to do IPv4 over
PPP, I would expect it to do IPv6 over PPP (preferably over the same PPP
session) when running in dual stack.

The "PPPoE" stack will use IPv6CP for WAN IP address configuration, and
DHCPv6 for other config options.

2. The document seems to suggest that "numbered" vs. "unnumbered" model
is a configuration option (section 5.3.2). I think the CPE router needs
to be able to automatically detect what the access network is giving it.
It should be pretty apparent if the access network is giving it a global
IP address or not.

3. I disagree with the behavior suggested for "unnumbered" model. I
don't think a CPE router should automatically open up a maintenance
loopback interface just because it doesn't get a global IP address. If
this is a retail CPE router, I think it really shouldn't be setting up a
maintenance loopback interface by default. Our access network is
definitely considering not giving out global addresses to the WAN
interface, but we have no requirements for any "loopback" maintenance
interfaces at all. We have considered the possibility of a separate IP
address for our TR-069 management of the CPE routers that we supply, but
would want this to be a configurable option. As a default, we believe
that the global address that the CPE router selects for its LAN
interface is sufficient for all WAN-side Internet communication,
including VoIP, TR-069, ping, traceroute, etc. [I often do ping tests
from the router when my WAN is having problems].

The option for separate IP address for maintenance would need to be
configurable whether or not the CPE router gets a global address on its
WAN interface. It's not just for the "unnumbered" model.

By the way, when I hear about IPv6 and loopback interface in the same
sentence, I usually think about ::1 (or 127.0.0.1 in IPv4). I associate
loopback network interfaces with SNMP. I've never heard that phrase used
with respect to a TR-069 interface. We do not support SNMP for
management of consumer and small business CPE routers. If you want to
have a configurable option for a maintenance interface that uses a
different IP address, I would prefer using more generic language,
instead of SNMP language. That would also prevent confusion between ::1
and loopback "network" interfaces, for people like me. I also find other
references to SNMP MIBs to be, umm, not of interest to me (e.g., section
4). But since there's no requirement to support SNMP, I don't really
care -- I just find it odd that there seems to be an underlying implicit
assumption that SNMP is used for management.

When a CPE router does not get a global IP address on its WAN, I don't
understand why it would be recommended for the CPE router to use its
maintenance interface to launch subsequent DHCPv6 messages. I would
expect the link-local address on the regular WAN interface to be
sufficient for this (especially since I want to be able to have no
global address on the WAN, and no special maintenance interface). Even
if a router is configured to have a special maintenance (TR-069)
interface, I would only want to see that set up after getting the global
prefix, and would want the general WAN interface used for all DHCPv6 and
SLAAC.

4. I find it interesting that "LAN initialization before WAN
initialization" is considered a "mode" of operation in 5.5.1. It's
simply that LAN initialization must have no dependency on the existence
of any WAN IP interface. Link-local and ULA happen no matter what. Then
if the WAN gets a global prefix, the router does what it needs to do to
get global addresses to the host devices.

5. In section 6 it says "If the CPE router supports cascading of routers
through automatic prefix sub-delegation, the CPE router must support a
DHCPv6 server or DHCPv6 relay agent." I think that all CPE routers need
to be able to operate in a cascaded network, because that's what users
are doing today and will continue to do. I would like to see all CPE
routers be able to operate in a cascaded network, be able to hand out
prefixes (if there are prefixes to hand out), and be able to operate as
a DHCPv6 relay agent if the upstream router has no prefixes to hand out
(because the upstream router only has a /64 itself). I don't think this
should be an "if" statement. 

Barbara
Barbara Stark    AT&T

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 8 Jul 2008 16:14:13 -0400

Barbara,

Thanks for your input and review. Please see in line below between <hs>
and </hs>.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stark, Barbara
Sent: Tuesday, July 08, 2008 2:20 PM
To: [email-masked]
Subject: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Hi Hemant and Wes,

<hs>I don't see a problem with this PPP scenario for IPv6, especially
after we wrote our new section of 5.5.1 in the -01 draft. If we don't
find any gotchas with supporting dual-stack over the same PPP session,
we will mention the fact in the draft as a "nice thing to have" or maybe
even a must. If the DSL network supports IPv6 between the home and the
Service Provider(SP) network, then the PPP model you describe above
should work for IPv6. However, if DSL takes some time to be IPv6 ready
between home and the SP, then one model we are thinking of is for the
CPE Router to initiate a softwire to carry IPv6 over IPv4 in L2TPv2
tunnels. Thanks to Mark Townsley for clueing us in on softwires
(http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-08).
We plan to add a softwire section to -02 draft.
</hs>

<hs>
You are correct. We kept the "numbered" vs. "unnumbered" model as a
configuration option because the unnumbered model is spawning a Loopback
interface. We wanted to make sure that if unnumbered model is configured
the SP or user knows a Loopback interface is being spawned. Other than
that I agree with you that the CPE Router knows if the access network is
giving it a global IPv6 address or not.
</hs>

<hs>No problem. So if the SP is not doling out an IPv6 address to the
WAN interface, is the SP doling out an IA_PD option to the CPE Router?
If yes, then when global IPv6 addresses from the IA_PD get assigned to
the LAN interface(s) of the CPE Router, one can always use one more
global address to configure on the WAN interface. However, if an SP does
not like assigning of a global IPv6 address to the WAN interface, that's
is fine with he CPE Router for PPP. Further, if the SP does not dole out
an IA_PD but assigns one IPv6 global address to the LAN interface(s),
that's a model the CPE Router also does not have a problem with
supporting for PPP. However, for non-PPP cases, the CPE Router will need
a global IPv6 address on the WAN interface and the WAN prefix must be
different from the LAN prefixes because the WAN and LAN interface(s) are
two separate routing domains of the CPE Router. We have received
feedback from you (AT&T), NTT (Japan), and some folks in Europe. We will
work on the text of our document to be general enough that we satisfy
all folks.
</hs>

<hs>
Loopback interfaces are also frequently used when discussing routing
protocols (not just SNMP), and have become commonplace in discussion of
router behavior.  Configuring a loopback interface on a router should
not be an onorous requirement. 
</hs>

global address on the WAN, and no special maintenance interface). 

<hs>
The reason is because DHCPv6 needs to ride on the link-local address of
the network interface initiating the DHCPv6. We are assigning a global
IPv6 address to the Loopback interface using DHCPv6. The WAN interface
has to remain with just a link-local address. It's funny as heck to have
the WAN interface initiate DHCPv6 using the link-local address of the
WAN interface but after DHCPv6 is completed, the IA_NA from DHCPv6 gets
assigned to the loopback interface. The draft clearly says, the Loopback
interface on the CPE Router also acquires a link-local address. 
</hs>

Even if a router is configured to have a special maintenance (TR-069)
interface, I would only want to see that set up after getting the global
prefix, and would want the general WAN interface used for all DHCPv6 and
SLAAC.

<hs>
It's a boot mode, not a mode of operation. We had to call it something
because our document is general enough that this CPE Router can be
embedded in a cable or DSL modem or any other device. Then the "LAN
initialization before WAN initialization" is not applicable. Cable
standards have already defined a "WAN initialization before LAN
initialization" embedded router specification in a cable modem. We have
to take care of that deployment too.
</hs>

<hs>
Again, the cable standards have specified a eRouter cable modem
specification that may not support cascading of routers. We will keep
the if. 
</hs>

Thanks.

Hemant & Wes.

Barbara
Barbara Stark    AT&T

*****

material from all computers. GA623

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 11:34:29 -0400

Barbara,

Since Antonio also raised a point about IPv6 addresses assigned to the
WAN interface (and the number of WAN interface(s)), we are combining a
reply to both you and Antonio. 

Barbara, when you say, 

"We have considered the possibility of a separate IP address for our
TR-069 management of the CPE routers that we supply, but would want this
to be a 
configurable option."

could you please elaborate. Does this separate IPv6 address get assigned
to the WAN side of the CPE Router? If yes, if the WAN interface is only
assigned a link-local address, then what network interface on the WAN
side does this IPv6 address get assigned to? One choice we have is to
assign the IPv6 address to the Loopback interface facing the WAN side.
Also, when reviewers ask for another network interface on the WAN side,
or another IPv6 address on the WAN side, could reviewers please
appreciate the fact that another WAN interface can mean two things for a
router. Either we have second physical WAN interface with a new
mac-address or we still have one WAN interface and the second WAN
interface is just a logical interface bound to the physical WAN
interface such that both the physical WAN interface and the logical
interface share a mac-address between them. Antonio and Barbara, which
one of these two interfaces are you talking about? Further, if one is
spawning logical interfaces on any router, once doesn't have to stop at
one extra interface. Go ahead and spawn more if one wants. 

Further, Antonio, when you say,

"Additionally, for those vendors that wish to integrate the layer 2
(DSL/cable) modem as part of the CPE router (where the "WAN"
encapsulation is not ethernet), perhaps a separately named interface
definition might be appropriate to avoid confusion with "WAN"."

In such a case, the WAN interface is a logical interface that bridges
the CPE Router to the broadband modem. We clarified the WAN interface
definition as follows with new text

WAN interface - a single physical network interface on the standalone
CPE Router that is used to connect the router to the access network of
the Service Provider. When the CPE Router is embedded in a device that
connects to the WAN, this interface is a logical network interface that
bridges the device to the CPE Router. Some devices which can have an
embedded CPE router are: a cable or DSL modem, or a cellular telephone,
etc. 

When we publish our next revision of the draft, we will include new text
for the WAN interface definition.

Thanks.

Hemant & Wes.

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

Hi Hemant and Wes,

Barbara
Barbara Stark    AT&T

*****

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 13:14:48 -0400

Comments in-line. 
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 11:34 AM
To: Stark, Barbara; [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Barbara, when you say, 

could you please elaborate. Does this separate IPv6 address get assigned
to the WAN side of the CPE Router? 
<Barbara>
One idea is that if a CPE router acquires a global address (SLAAC or
DHCPv6 on the WAN), that it would use this for the TR-069 management
interface, and it would use a global address from the prefix its given
for all other Internet communication. Some people think it would improve
security of that management interface (because of the ability in the
access network to control what traffic goes to/from that IP address).
Others consider it unnecessarily complex. The preferred approach (by
those who think having a separate management interface is too complex)
would be for CPE routers to use one of the addresses from the assigned
prefix for all Internet communication (between the CPE router and the
Internet), independent of whether it acquired a global address through
SLAAC/DHCPv6. The address acquired through SLAAC/DHCPv6 would only be
used to communicate with the access network (DHCPv6, ND, etc.).
</Barbara>

If yes, if the WAN interface is only
assigned a link-local address, then what network interface on the WAN
side does this IPv6 address get assigned to? 
<Barbara>
I'm experiencing some confusion here -- I thought that any given
"interface" could have multiple IPv6 addresses associated with it, and
it would simply need to have rules as to which address to use for which
traffic. The CPE router uses the address acquired from the access
network for DHCPv6, ND, etc., and it uses a global address from the
prefix for communication with other global addresses (not in its
prefix). Why do you believe separate interfaces may be needed?
</Barbara>

One choice we have is to
assign the IPv6 address to the Loopback interface facing the WAN side.
<Barbara>
We don't have such a LAN-facing loopback interface in any of our mass
market CPE, that I'm aware of. And I don't think we intend to start.
</Barbara>

Also, when reviewers ask for another network interface on the WAN side,
or another IPv6 address on the WAN side, could reviewers please
appreciate the fact that another WAN interface can mean two things for a
router. Either we have second physical WAN interface with a new
mac-address or we still have one WAN interface and the second WAN
interface is just a logical interface bound to the physical WAN
interface such that both the physical WAN interface and the logical
interface share a mac-address between them. Antonio and Barbara, which
one of these two interfaces are you talking about? Further, if one is
spawning logical interfaces on any router, once doesn't have to stop at
one extra interface. Go ahead and spawn more if one wants. 
<Barbara>
I mostly agree with this description of logical and physical interfaces,
although it can be more complex with DSL, and I consider Ethernet PHY to
be physical, but Ethernet link layer to be logical. A single physical
ADSL connection can have multiple ATM PVCs. An ATM PVC can support
multiple PPPoE sessions (although each ATM PVC only has a single
Ethernet "interface"), in which case each PPPoE session would also be an
"interface". It's also possible to bond multiple physical DSL
connections into a single logical connection (at the ATM or Ethernet
layer). I think that in these IPv6 discussions, I'm referring to an
interface at the Ethernet link layer. I think that should be considered
"logical", and physical would be DSL PHY, Ethernet PHY, etc. I'm
definitely not referring to the PHY interface. PHY needs to be
completely independent of IPv6 (and IPv4) discussions, IMO.
</Barbara>

WAN interface - a single physical network interface on the standalone
CPE Router that is used to connect the router to the access network of
the Service Provider. When the CPE Router is embedded in a device that
connects to the WAN, this interface is a logical network interface that
bridges the device to the CPE Router. Some devices which can have an
embedded CPE router are: a cable or DSL modem, or a cellular telephone,
etc. 
<Barbara>
I really think that we should focus on WAN interface at the Ethernet
link layer. Each MAC address presented to the WAN is a separate
interface. Since I'd also like for this document to apply equally to
Ethernet-PHY-to-the-WAN CPE routers (including ones that may get
cascaded inside the LAN), I would recommend a more general and simpler
description, such as:
WAN interface - an Ethernet link layer interface on the CPE Router that
is used to connect the router to the access network of the Service
Provider or to other CPE routers that are between it and the access
network. 

When there is a single WAN interface enabled on a CPE router, it's not
necessary to use RIP or have static routing entries to determine how to
route traffic to the WAN. When there are multiple WAN interfaces
enabled, it is necessary. When there are multiple WAN interfaces with an
IPv6 stack enabled, I would expect each of them to do SLAAC/DHCPv6 and
request a prefix. If each is assigned a prefix, I would expect each of
them to place IPv6 addresses from that prefix on the various LAN
interfaces, and to advertise that prefix or assign addresses from it to
devices on the LAN. That is, each WAN interface would meet the
requirements in this document. 

It's also possible to have multiple PPPoE sessions over a single
Ethernet link layer interface. In this case, each PPPoE session would
need to behave like a "WAN interface". But I don't see the need to go
into that level of detail in this document.
</Barbara>

Thanks.

Hemant & Wes.

--- Barbara snipped off the rest of the original email ---

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 15 Jul 2008 08:00:08 -1000 (HST)

On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote:

> Date: Tue, 15 Jul 2008 11:34:29 -0400
> To: "Stark, Barbara" <[email-masked]>, [email-masked]
> Cc: Antonio Querubin <[email-masked]>

Actually the discussion is confusing because the 'WAN' interface appears 
to mean different things depending on whether the layer 2 modem is 
integrated into the CPE router.  For discussion purposes, in a general 
network configuration where all the components are separate you'll have:

                     PCs
                      |
                      |
                      |
----- modem ----- switch ----- router/firewall ----- switch ----- PCs
   1     A     2      B     3         C           4      D     5    E

Devices B and D are just plain ethernet switches.  Although the focus of 
this document seems to be on device C, it's interfaces, and the customer 
devices (E) behind it, the CPE router being discussed potentially 
encompasses functionality of devices A, B, C, and D.

In the case where the modem is integrated, the interface that internally 
links the modem to the internal router device C may or may not be 
accessible to the consumer via external physical ports.  If they are 
physically accessible, they need a different name than "WAN" if "WAN" is 
defined to be 1 above.

If the modem is not integrated into your CPE device, then the "WAN" 
interface is just 2 and/or 3 above depending on whether additional "WAN" 
ports are provided by the vendor.

However these multiple definitions of WAN interfaces are confusing, hence 
my earlier suggestion of using different names for the modem-router 
interface and the access provider interface.

> for the WAN interface definition.

How about this.  If you want to tie the WAN interface to the internal 
router:

WAN interface - a network interface on the CPE Router that is used to 
connect the router to the access network of the Service Provider.  When a 
CPE Router is embedded in a device that connects to the service provider 
via a non-ethernet connection, this interface is the logical interface 
that connects the internal router to the internal bridge.  Some devices 
which can have an embedded CPE router are: a cable or DSL modem, or a 
cellular telephone, etc.

SPA (service provider access) interface - a non-ethernet physical network 
interface that is bridged to the WAN interface and directly connects to 
the access network of the Service Provider.

But if you want to keep the definition of WAN tightly coupled with the 
physical external port then something like this might be more suitable:

WAN interface - a network interface on the CPE Router that is used to 
connect the router directly to the access network of the Service Provider. 
When a CPE Router is embedded in a device that connects to the service 
provider via a non-ethernet connection, this physical interface is bridged 
to the router via an internal modem.  Some devices which can have an 
embedded CPE router are: a cable or DSL modem, or a cellular telephone, 
etc.

WANEA (WAN Ethernet Access) interface - an optional ethernet interface 
that is bridged to the WAN interface and provides additional direct access 
to the Service Provider network.

You may want to call it something other than WANEA :)

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 14:20:13 -0400

I meant to say in my previous email: "We don't have such a WAN-facing
loopback interface in any of our mass market CPE, that I'm aware of. And
I don't think we intend to start."
Barbara
---------------------------------------------------------
---- snip -----
One choice we have is to

*****

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 15:08:14 -0400

Comments in line below between <hs> and </hs>. 

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 1:15 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Comments in-line. 
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 11:34 AM
To: Stark, Barbara; [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Barbara, when you say, 

"We have considered the possibility of a separate IP address for our
TR-069 management of the CPE routers that we supply, but would want this
to be a configurable option."

<hs>
Ah, just confusion on our side and also because we haven't read the
TR-069 document yet. We thought, it's another network interface being
discussed for management. To make sure we understand your statements
above, here is what we think you are saying:
The WAN interface gets a link-local address that is used by DHCPv6 and
ND. The WAN interface also gets a global IPv6 address (doesn't matter,
if the global is an IA_NA from DHCPv6 or an address out of the IA_PD
prefix doled out to the WAN interface) that is used for management  and
any other communication.
</hs>

One choice we have is to

<hs>
The CPE Router is a router for which a network Loopback interface is
very normal. Other folks have asked us for this Loopback interface, so
we are going to be very careful changing the draft for the Loopback
interface. However, it's optional to be configured. But then you will
have to use the Numbered model of our document and assign a global IPV6
to the WAN interface.
</hs>

<hs>
Yes, the OSI model says PHY needs to be independent of IPv6 and IPv4 at
layer 3. So are we on the same page that you and Antonio need only one
Ethernet physical WAN interface, but there may, of course, be any number
of logical interfaces bound to the physical Ethernet interface. Please
let's make sure, if anyone needs more than one physical port for the WAN
side of the CPE Router - please speak up if you do.
<hs>

<hs>
Good suggestion. We'll consider this text when we prepare a new
definition of the WAN interface based on other people's reply too.
</hs>

When there is a single WAN interface enabled on a CPE router, it's not
necessary to use RIP or have static routing entries to determine how to
route traffic to the WAN. 

<hs>
Not quite. What happens to the traffic from the Service Provider (SP) to
the home? The aggregation router (agg rtr) needs to know routes to the
home to send data to the home. RIPv6 is one option via which the home
sends its route information (routes to PD) to the agg rtr.
Alternatively, the agg rtr may snoop DHCPv6 message and inject routes in
the agg rtr for the PD's in DHCPv6 messages. There may be yet a third
solution that we are not going into.
</hs>

Thanks.

Hemant & Wes

When there are multiple WAN interfaces enabled, it is necessary. When
there are multiple WAN interfaces with an
IPv6 stack enabled, I would expect each of them to do SLAAC/DHCPv6 and
request a prefix. If each is assigned a prefix, I would expect each of
them to place IPv6 addresses from that prefix on the various LAN
interfaces, and to advertise that prefix or assign addresses from it to
devices on the LAN. That is, each WAN interface would meet the
requirements in this document.

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 16:17:18 -0400

I don't understand the relevance of mentioning PHY interfaces, PHY
modems, or pure Ethernet switches, in a document about IPv6 behavior of
CPE routers. A physical instantiation of a CPE router may indeed contain
a PHY modem and Ethernet switch, but I don't see why that's relevant or
needs to be called out in this document.

I don't see any functionality described in this draft that changes based
on the link layer or below. Certainly not if the link layer is Ethernet.

I know that there do exist WAN PHY interfaces that do not have the IP
running over either  Ethernet link layer or PPP. Such IP interfaces will
either exhibit the same behavior as described in this document, or they
won't. If they do, that can be mentioned. If they don't, but have mass
market relevance, it can be described how they differ. The WAN interface
as an Ethernet link layer interface will cover all mass market retail
routers, and the vast majority of DSL modem/routers. I can't speak for
DOCSIS or UMTS, since I don't know those protocol stacks very well. If
they don't use Ethernet for their link layers, do they have some other
link layer that is similar to Ethernet? Is there any reason why that
link layer shouldn't be considered the "WAN interface"?
Barbara

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

However these multiple definitions of WAN interfaces are confusing,
hence 
my earlier suggestion of using different names for the modem-router 
interface and the access provider interface.

WAN interface - a network interface on the CPE Router that is used to 
connect the router to the access network of the Service Provider.  When
a 
CPE Router is embedded in a device that connects to the service provider

SPA (service provider access) interface - a non-ethernet physical
network 
interface that is bridged to the WAN interface and directly connects to 
the access network of the Service Provider.

WAN interface - a network interface on the CPE Router that is used to 
connect the router directly to the access network of the Service
Provider. 
When a CPE Router is embedded in a device that connects to the service 
provider via a non-ethernet connection, this physical interface is
bridged 
to the router via an internal modem.  Some devices which can have an 
embedded CPE router are: a cable or DSL modem, or a cellular telephone, 
etc.

WANEA (WAN Ethernet Access) interface - an optional ethernet interface 
that is bridged to the WAN interface and provides additional direct
access 
to the Service Provider network.

Antonio Querubin
whois:  AQ7-ARIN

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 15 Jul 2008 10:39:36 -1000 (HST)

> side of the CPE Router - please speak up if you do.

If you're talking about an ethernet interface bridged to the WAN side, 
then I'd say it's highly recommended.  If the device is an all-in-one 
integrated device and you have to test the provisioning of the service 
provider connection, it's easy to just have the customer move a PC 
temporarilly onto the extra WAN access port and troubleshoot from there. 
The only thing between the PC being used for diagnosis and the Service 
Provider is the internal modem.  Furthermore, some customers may want to 
have a plug-n-play DMZ outside of their router firewall domain.  For 
simplicity of managing policy, this latter scenario probably would imply 
that the /64 assigned to the WAN link shouldn't overlap with the prefix 
delegated to the LAN interface(s) of the router but even that's not 
necessarilly a hard requirement.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 16:38:59 -0400

I disagree that if the loopback interface is not configured "you will
have to use the Numbered model of our document and assign a global IPV6
to the WAN interface". Just to be sure, I think you're saying that the
CPE router will need to get a global IPv6 address via SLAAC or stateful
DHCPv6, from the access network. I do not see any reason why the CPE
router cannot use one of the addresses from its assigned prefix. Since
we are definitely considering using the "unnumbered model", and we have
no loopback interface in our devices (and have no intention of having
them), I think I'm going to have to try to get a second opinion on this.
Does anyone else have an opinion on whether or not the "unnumbered
model" will only work in the presence of a loopback interface?

By the way, I've never seen such a loopback interface in any mass market
retail CPE routers. To me, the capabilities found in such mass market
routers should be the benchmark for "very normal". I'm also not familiar
with it in DSL routers. DSL routers are also "very normal", worldwide.
I've been trying to search the Internet for products that include this
interface, and all I can find are Cisco products with IOS. I'm curious
as to whether any other vendors implement this interface, and, if so, on
what sorts of mass market products.
Barbara

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 1:15 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Comments in-line. 
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 11:34 AM
To: Stark, Barbara; [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Barbara, when you say, 

<hs>

One choice we have is to

<hs>

<hs>

<hs>

<hs>

Thanks.

Hemant & Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 16:50:52 -0400

Barbara,

Thanks for this email. For the purposes of description of behavior of a
CPE Router, all we are asking for is how many physical WAN interface
ports will the CPE Router have? We have recommended one. We could care
less about any other physical layer behavior. We are defining routing
behavior that sits abstracted from link or physical layers. Where a
layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP
address acquisition does not perform DAD. 

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

However these multiple definitions of WAN interfaces are confusing,
hence my earlier suggestion of using different names for the
modem-router interface and the access provider interface.

WAN interface - a network interface on the CPE Router that is used to
connect the router to the access network of the Service Provider.  When
a CPE Router is embedded in a device that connects to the service
provider

SPA (service provider access) interface - a non-ethernet physical
network interface that is bridged to the WAN interface and directly
connects to the access network of the Service Provider.

WAN interface - a network interface on the CPE Router that is used to
connect the router directly to the access network of the Service
Provider. 
When a CPE Router is embedded in a device that connects to the service
provider via a non-ethernet connection, this physical interface is
bridged to the router via an internal modem.  Some devices which can
have an embedded CPE router are: a cable or DSL modem, or a cellular
telephone, etc.

WANEA (WAN Ethernet Access) interface - an optional ethernet interface
that is bridged to the WAN interface and provides additional direct
access to the Service Provider network.

Antonio Querubin
whois:  AQ7-ARIN

*****

material from all computers. GA621

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 15 Jul 2008 10:51:05 -1000 (HST)

> needs to be called out in this document.

Only because the definition of WAN thus far specifically mentions a strict 
single physical interface port count.  If however, we want to get away 
from that wording altogether, then I would concur with you.  It's then up 
to the vendor to decide if they want to provide the extra functionality of 
additional interfaces bridged to the WAN.  There are good reasons for 
doing so but I agree they do not need to be in this document.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 17:09:32 -0400

I and Wes are working with NTT, Japan as well and they clearly support
the WAN interface on the CPE Router to acquire a global IPv6 address.
NTT also happens to have a functional IPv6 ADSL deployment that is few
years old.  We listen more to working deployments than any requests from
folks that still not don't seem to be complete with their IPv6 thinking
for DSL.  I am meeting with NTT folks in Dublin to iron out some details
for the CPE Router - unless I close with them, our CPE Router document
is still subject to change.  We will certainly work with AT&T till we
have a plan in place for them too. 

BTW, I and Wes work in the Cable industry and build cable aggregation
routers (CMTS) for a living.  Our cable deployment has completed
standards, and CMTS and cable modems working as of 2 years back for
IPv6. Our deployment also uses a global IPV6 address for the WAN
interface of the cable modem.

I have a simple bottom-line. The CPE Router does have two separate
routing domains in the WAN and LAN interface(s).  Routing domains need
their own global IPv6 addresses and different subnets. There is also no
dearth of IPv6 global addresses, so I don't see what the problem is if
the WAN interface get a global IPv6 address.

I agree with you that Loopback interfaces are not common to home
Linksys-like routers.  But, IPv6 being a new and different space
(everything from IPv4 cannot map as is to IPv6), if a Loopback meets a
requirement for one operator, it was worth considering. 

Hemant

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 1:15 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Comments in-line. 
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 11:34 AM
To: Stark, Barbara; [email-masked]
Cc: Antonio Querubin
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Barbara, when you say, 

<hs>

One choice we have is to

<hs>

<hs>

<hs>

<hs>

Thanks.

Hemant & Wes

---

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 15 Jul 2008 17:33:43 -0400

I would prefer if no statements were made as to number of physical WAN
interfaces. We have some bonded DSL interfaces that have 2 physical
interfaces that are bonded together at either the ATM or Ethernet layer.
There are 2 physical WAN interfaces, but from the perspective of the IP
portion of the access network, there is only one "logical" WAN interface
on the router.

I really would prefer to describe the behavior of a single link layer
(L2) interface, rather than make any mention of physical interfaces
(quantity, PHY, jack, or otherwise). I agree with your statement that
this document's functionality needs to be abstracted from the physical.
I really, really agree.
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 15 Jul 2008 11:44:56 -1000 (HST)

> CPE Router, all we are asking for is how many physical WAN interface

On the one hand you say                         ^^^^^^^^

> behavior that sits abstracted from link or physical layers. Where a
                      ^^^^^^^^^^^^^^^         ^^^^^^^^
On the other hand you say

> address acquisition does not perform DAD.

Why not just call it a routed interface and get away from the word 
physical altogether?

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 18:34:14 -0400

Barbara,

Thanks very much for this feedback from the DSL world. I agree with you
then that any mention of physical interfaces can be skipped. BTW, do
note that we have tried to keep our LAN interfaces of the CPE Router
behavior very agnostic to number of LAN interfaces or jacks or physical
port - I believe we have done alright with that. So it won't be a
problem for us to keep the WAN interface text from being one WAN
physical interface centric to WAN interface(s). 

BTW, in cable industry, we also do bond multiple physical channels with
docsis 3.0, but we still have one single RF connector out of the cable
modem. That is why we are used to referring to one physical WAN
interface and also not seeing the need for more than one WAN physical
interface.

If no one objects, we will make such an update to our next version of
the draft. My cohort is away on vacation till mid next week. Anyhow, I
believe we cannot publish a new version of our draft to IETF till after
August 1st when IETF 72 ends. We will try to clear up some more things
in our draft during August.

Hemant

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

material from all computers. GA622

---

From: "Ole Troan" <[email-masked]>
Date: Wed, 16 Jul 2008 00:56:01 +0200

Barbara,

> what sorts of mass market products.

the loopback interface is a red herring. the unnumbered model will
work just fine without it.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 18:57:09 -0400

Antonio,

BTW, we don't mention physical interfaces anywhere in the draft from day
one of -00 to -02 versions of the draft. I am just asking a question if
anyone sees a need for more than one physical WAN ports on the CPE
Router. Barbara has already replied and I replied to her - we are not
going to add any mention of number of physical WAN ports for the CPE
Router. 

As for your comment below, even a router needs to run ND at layer 2.
Besides, routing, we do plan to cover minor and relevant ND behavior for
the CPE Router in our draft.  We had to mention physical interface in
the attempt for a new definition of the WAN interface to clarify the WAN
interface on the standalone CPE Router vs. the WAN interface when the
CPE Router gets embedded in a device like a broadband modem.  I thought
we were clear from our new definition (shown below) from this morning to
delineate between embedded CPE Router vs. standalone CPE Router. 

WAN interface - a single physical network interface on the standalone
CPE Router that is used to connect the router to the access network of
the Service 
                         ^^^^^^^^                          ^^^^^^^^^^
Provider. When the CPE Router is embedded in a device that connects to
the WAN, this interface is a logical network interface that bridges the
device to the CPE Router. Some devices which can have an embedded CPE
router are: a cable or DSL modem, or a cellular telephone, etc. 

I know now, "single" doesn't work above - that can be easily massaged
out of the definition. Further, it's not that easy to call the WAN
interface as a routed interface because soon as the interface becomes an
internal interface in an embedded device, the WAN interface is a bridge
to the broadband modem internal interface so that the CPE Router gets
all IPv6 traffic from the broadband modem. 

We have heard your comments. We'll see what we can do to make the text
more clear for WAN interface and embedded vs. standalone delineation. 

Thanks.

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 5:45 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote:

> Thanks for this email. For the purposes of description of behavior of 
> a CPE Router, all we are asking for is how many physical WAN interface

                      ^^^^^^^^^^^^^^^         ^^^^^^^^

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 19:08:15 -0400

BTW, we have already replied to Barabara on July 8th that unnumbered
model that she proposed by giving global IPv6 addresses to LAN
interface(s) and only a link-local to WAN interface(s) is fine for the
CPE Router. See the email exchange below. I was just warning today that
for routing functionality, we just need a global IPv6 address on the WAN
interface. After all, the CPE Router is a router.

However, we didn't still not make any change in our -02 draft for
Loopback interface because we want to first see if a common model for
the CPE Router can be found between AT&T, NTT, and other European DSL
folks. 

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Tuesday, July 15, 2008 6:56 PM
To: Stark, Barbara
Cc: Hemant Singh (shemant); [email-masked]; Antonio Querubin
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

> have to use the Numbered model of our document and assign a global 
> IPV6 to the WAN interface". Just to be sure, I think you're saying 
> that the CPE router will need to get a global IPv6 address via SLAAC 
> or stateful DHCPv6, from the access network. I do not see any reason 
> why the CPE router cannot use one of the addresses from its assigned 
> prefix. Since we are definitely considering using the "unnumbered 
> model", and we have no loopback interface in our devices (and have no 
> intention of having them), I think I'm going to have to try to get a
second opinion on this.
> By the way, I've never seen such a loopback interface in any mass 
> market retail CPE routers. To me, the capabilities found in such mass 
> market routers should be the benchmark for "very normal". I'm also not

> familiar with it in DSL routers. DSL routers are also "very normal",
worldwide.

> as to whether any other vendors implement this interface, and, if so, 
> on what sorts of mass market products.

the loopback interface is a red herring. the unnumbered model will work
just fine without it.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 19:10:22 -0400

Barbara,

Did you get a chance to look at our -02 draft and its reference to
RFC4241? Please read RFC4241 to see what has NTT done in Japan to their
ADSL IPv6 services.

Thanks.

Hemant 

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

---

From: "Ole Troan" <[email-masked]>
Date: Wed, 16 Jul 2008 01:12:39 +0200

> interface. After all, the CPE Router is a router.

I don't understand your last sentence. why do you need a global
address on the WAN interface because the CPE router is a router??

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 15 Jul 2008 19:54:21 -0400

Ole said: why do you need a global address on the WAN interface because
the CPE router is a router??

RPF (Reverse Path Forwarding) will fail and if RPF fails for a router,
due to security concerns, the router should drop the incoming packet. If
the WAN interface of the CPE Router does not have a global IPV6 address,
how is RPF going to work? RPF needs global IPv6 addresses.

We haven't looked at the problem with a fine tooth and comb but when we
do we will list all cases for what IPv6 routing and data forwarding
breaks down if a routed interface of a router has only a link-local
address.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Tuesday, July 15, 2008 7:13 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]; Antonio Querubin
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

> CPE Router. See the email exchange below. I was just warning today 
> that for routing functionality, we just need a global IPv6 address on 
> the WAN interface. After all, the CPE Router is a router.

I don't understand your last sentence. why do you need a global address
on the WAN interface because the CPE router is a router??

/ot

---

From: "Ole Troan" <[email-masked]>
Date: Wed, 16 Jul 2008 02:01:48 +0200

Hemant,

> how is RPF going to work? RPF needs global IPv6 addresses.

that is incorrect. you do not need a global address to verify the SA.
we could go into details on "RPF checking", but before that, why do
you even want RPF checking on a CPE router, that belongs on the
provider edge.

> breaks down if a routed interface of a router has only a link-local

as I have said multiple times before I am not aware of any, nor have I
seen anyone else cite any examples.

/ot

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 15 Jul 2008 15:17:24 -1000 (HST)

> how is RPF going to work? RPF needs global IPv6 addresses.

I'm confused.  How would RPF fail if the router will normally have a 
default route out the WAN interface?

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 15 Jul 2008 15:21:30 -1000 (HST)

> you even want RPF checking on a CPE router, that belongs on the

On the WAN side to prevent spoofed packets from entering the customer's 
network.  On the LAN side to prevent a customer's network that's been 
overrun from sending spoofed packets to the service provider's network. 
Doing it at the CPE prevents those packets from overwhelming the WAN link.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Jul 2008 07:43:47 -0400

Even if the CPE Router has a default router out the WAN interface to the
SP router, RPF may support a knob where "Allow default route to match
when checking source address" is not allowed.  One can configure a
router to disable checking the default route to match src-addr by RPF.

shark(config-if)#ipv6 verify unicast source reachable-via rx ?
  WORD           Access-list name
  allow-default  Allow default route to match when checking source
address
  <cr>

I have a spoofed packet with global src-addr input to the WAN interface
of a standalone CPE Router - the destination of this packet is the
global IPv6 address of a LAN interface.  Strict uRPF check will check if
the src-addr is reachable by a path thru the input interface which is
the WAN interface. The WAN interface, which is also a routed port has
only a link-local address.  So how can the global address have a path
thru the WAN interface that is assigned only a link-local address?

In general, if one even issues a ping to a global address and the ping
has to go out the WAN interface which only has a link-local address
configured, the ping will fail to head out because there is no valid
source address for destination.  See a test from my IPv6 Cisco router
where I have assigned only a link-local address to the network interface
(FE80::205:FF:FEE0:74CE) that is supposed to send the ping out. 

shark#ping 2001:420:3800:800:203:BAFF:FE11:B644

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:420:3800:800:203:BAFF:FE11:B644,
timeout is 2 seconds:

% No valid source address for destination
Success rate is 0 percent (0/1)
shark#
shark#sh ipv6 int br
Ethernet0/0/0              [up/up]
    unassigned
FastEthernet0/0/0          [up/up]
    FE80::205:FF:FEE0:74CE

Hemant  

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 9:17 PM
To: Hemant Singh (shemant)
Cc: Ole Troan; Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

On Tue, 15 Jul 2008, Hemant Singh (shemant) wrote:

> Ole said: why do you need a global address on the WAN interface 
> because the CPE router is a router??
>

> due to security concerns, the router should drop the incoming packet. 
> If the WAN interface of the CPE Router does not have a global IPV6 
> address, how is RPF going to work? RPF needs global IPv6 addresses.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Jul 2008 07:52:48 -0400

See RFC4241 and section 2.8 that says:

[To achieve this requirement, for example, once the prefix
   2001:db8:ffff::/48 is delegated, the CPE must reply to the ICMPv6
   Echo Request destined for 2001:db8:ffff:: any time that IPV6CP and
   DHCPv6-PD are up for the upstream direction.  Because some
   implementations couldn't reply when 2001:db8:ffff::/64 was assigned
   to its downstream physical interface and the interface was down, such
   an implementation should assign 2001:db8:ffff::/64 for the loopback
   interface, which is always up, and 2001:db8:ffff:1::/64,
   2001:db8:ffff:2::/64, etc., to physical interfaces.]

NTT's ADSL deployment is already using a Loopback interface and why.

Hemant  

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

Barbara,

second opinion on this.

worldwide.

/ot

---

From: "Ole Troan" <[email-masked]>
Date: Wed, 16 Jul 2008 14:19:04 +0200

> thru the WAN interface that is assigned only a link-local address?

see RFC3704.
the uRPF check is done in the FIB. independent of addresses configured
on the interfaces (apart from installed connected routes of course).

I don't see much value in running uRPF on receive for the WAN
interface. what isn't going to match the default route. you are only
protecting yourself from receiving packets spoofed with a source from
your own address space. as Antionio pointed out, doing it on the LAN
side has value.

> (FE80::205:FF:FEE0:74CE) that is supposed to send the ping out.

that is also incorrect, and I can say that with some level of
confidence since I wrote the IOS source address selection code in my
previous life.
IOS implements the weak host model, and will use an address from
another interface if the outgoing interface doesn't have an address of
sufficient scope. you need to have at least _one_ address configured
on the box obviously.

this is in any case host behaviour.you said: "...IPv6 routing and data
forwarding breaks down if a routed interface of a router has only a
link-local address." any other examples?

/ot

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 16 Jul 2008 03:18:55 -1000 (HST)

> router to disable checking the default route to match src-addr by RPF.

Aren't we talking about a single-homed router?  On a mass-market consumer 
router with one logical WAN interface connected to a service provider's 
edge, how likely would such a knob be used?  Asymmetrical routing is 
proably not a significant factor.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Jul 2008 10:13:56 -0400

Antonio,

Please see in line below.

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Wednesday, July 16, 2008 9:19 AM
To: Hemant Singh (shemant)
Cc: Ole Troan; Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

On Wed, 16 Jul 2008, Hemant Singh (shemant) wrote:

> Even if the CPE Router has a default router out the WAN interface to 
> the SP router, RPF may support a knob where "Allow default route to 
> match when checking source address" is not allowed.  One can configure

> a router to disable checking the default route to match src-addr by
RPF.

Aren't we talking about a single-homed router? 

<hs 
Yes.
</hs>

On a mass-market consumer router with one logical WAN interface
connected to a service provider's edge, how likely would such a knob be
used?  
Asymmetrical routing is proably not a significant factor.

<hs>
Folks may think the knob is less likely to be used. Asymmetrical routing
may be likely for the CPE Router because besides the default router, as
our draft says, RIPv6 may optionally run between the CPE Router and the
SP aggregation router. You see, all folks in this discussion have said,
RIPv6 is not needed. But when they said it's not needed they are talking
about the upstream direction from the CPE Router to the SP. It's the
downstream direction that is interesting. I already said yesterday, for
the direction of RP to the CPE Router, how does the SP aggregation
router know the routes to the PD's assigned to the CPE Router? In the
March IETF, folks presented one solution (to v6ops) on how does the SP
aggregation router learn routes to PD's in the downstream. IETF has
still not standardized one solution for this problem nor am I sure if
IETF would like to standardize such a solution. In the meantime, we are
saying one may use RIPv6 to solve the problem. The other alternative is
to have the aggregation router support DHCPv6 snooping for the IA_PD and
then inject a route for the PD. 
</hs>

Hemant

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 16 Jul 2008 10:36:22 -0400

Sorry, I had two typos in the email below. Here are the fixed sentences
for typos shown in quotes.

[Asymmetrical routing may be likely for the CPE Router because besides
the default "route", ...]

and

[for the direction of "SP" to the CPE Router]

Hemant

-----Original Message-----
Sent: Wednesday, July 16, 2008 10:14 AM
To: Antonio Querubin

Antonio,

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Wednesday, July 16, 2008 9:19 AM
To: Hemant Singh (shemant)
Cc: Ole Troan; Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

RPF.

<hs
Yes.
</hs>

<hs>

Hemant

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 17 Jul 2008 13:46:30 -0400

I've looked over RFC4241. I think it accurately describes what needs to
happen in a generic PPPoE environment -- except the section "2.8.
Connectivity Monitoring". We do not currently require CPE routers to
respond to ICMP echo requests. It's even an option in some of our
routers for customers to disable responses to unsolicited ICMP messages.
And we still don't have something called a "loopback interface". I also
don't think we intend to provide a /48 in this mass market environment.
Probably the smallest prefix would be a /56. I haven't seen any ARIN
policy relating to required echo support, especially for an end customer
with a /56.

But I'm starting to wonder if we may just be experiencing another
terminology problem, with "loopback interface". 

That is, I definitely agree that all CPE routers need to have a global
address that can initiate and receive traffic to and from the Internet
(over each logical WAN interface -- at the link layer or over PPP). I
think this address can easily come from the prefix, and doesn't have to
be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The
CPE router must be able to act as a host device to the WAN.

Clearly, there will be a link-local IP address on that WAN (link layer
or PPP) interface. There may be a global IP address assigned by SLAAC or
stateful DHCPv6. If there is, I think it would be useful to think about
when the device might use or respond to messages to that global address,
vs. global addresses it gives itself from the prefix. My preference
would be to always use the prefix address for sending messages, by
default (that is, unless configured to do otherwise). Incoming traffic
to the SLAAC/DHCPv6 address might be blocked, by default (unless
configured otherwise). Unless the device doesn't get a prefix; then it
will need to use the SLAAC/DHCPv6 address.

I also think it's not a bad idea for the CPE router to keep the /64 for
itself that equates to the prefix it's given followed by zeroes, to get
to 64 bits (which is my attempt at trying to generically describe what I
think RFC4241 section 2.8 is saying). I think it's fine for the CPE
router to be able to respond to echo requests to that /64, if that
function (responding to echo requests from the WAN) is enabled.
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Tuesday, July 15, 2008 7:10 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Thanks.

Hemant 

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 14:35:05 -0400

Barbara,

Let me make sure I understand you. Are you agreeing to that fact that
the WAN interface should have a global IPv6 address assigned to it
because this is different from what you asked for in the past which was
to only assign a link-local address to the WAN interface. Also assume,
for the sake of closure to the question, that there is no Loopback
interface enabled on the CPE Router - after all, our draft says the
Loopback interface is optional.

Further, even I agree with you that it's not wise for a CPE Router to
respond to pings. But I appreciate what NTT did in their deployment
because how else can one monitor health of the device in the home? The
device has to at least rate limit ICMP if the device responds to it.
Section 2.8 of RFC4241 is also not clear when it says "The CPE must
return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo
Request packet." What happens if the CPE received another ping req, say,
2 secs later. Will the CPE reply? If yes, then I can launch a ping
attack on this CPE sending one pings per x secs and the CPE keeps
replying. That is why I mentioned rate limiting.

Hemant

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 7:10 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Thanks.

Hemant 

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 17 Jul 2008 17:10:53 -0400

I'm sorry to have caused you to think that I didn't want a global IP
address on the WAN interface! What I meant to express, was that I didn't
think a global IP address needed to be provided via SLAAC or stateful
DHCPv6, but that it could be taken from the prefix. The definition of
"Numbered Model" is very specific to getting the global address via
SLAAC or stateful DHCPv6, and not any other way. So either the "Numbered
Model" should also allow the global address to come from the prefix
(especially if none comes from SLAAC or stateful DHCPv6), or the
"Unnumbered Model" needs to mention that the WAN interface gets a global
address from the prefix. I'm fine either way.

Yes, the WAN interface absolutely *must* have a global IP address that
it uses for sending and receiving IP messages, as far as I'm concerned.

The "health" of the connection can be determined in a variety of ways.
PPP has messages for testing the PPP connection. I forget what the
access network uses in IPv4. I know that inside the home we use ARP (for
IPv4) to test whether the device is still there. There are also PHY and
L2 layer tests to see if those layers are working. I can go ask the
access network guys what we do for IP over Ethernet. In addition to
these access network methods, our devices have a "heartbeat". They are
expected to periodically "phone home" to the TR-069 server. For the
health of the device (above and beyond whether the IP connection is up
or down), we rely on TR-069. 

FYI: Note that TR-069 is just some remote procedure calls and XML config
parameters that run over (SOAP)/HTTPS/TCP/IP. Pretty basic. One big
difference between TR-069 and SNMP is that TR-069 requires the CPE to
initiate the connection (pull model). The XML config parameters are the
analog of SNMP MIBs.
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]] 
Sent: Thursday, July 17, 2008 2:35 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 7:10 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Thanks.

Hemant 

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Hemant

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

                     PCs
                      |
                      |
                      |

defined to be 1 above.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 17 Jul 2008 14:42:45 -0700

>Sent: Thursday, July 17, 2008 11:35 AM

I don't understand this. If it is a router, it follows
the weak end system model and it can source packets from
addresses assigned to any of its interfaces, including
virtual interfaces like a loopback. I do not see a
requirement for assignment of a non-link-local IPv6
address on the WAN interface.

Fred
[email-masked]

>> appreciate the fact that another WAN interface can mean two 
>things for
>a

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 17:46:56 -0400

Barbara,

No apologies needed!  Thanks for the quick reply back. So now, you from AT&T and Shin from NTT, Japan are on the same page wrt global IPv6 address on the WAN interface. Shin has also asked for a global IPv6 address as a must for the WAN interface. From the -00 version of our draft we have been saying the WAN interface acquires a global address. Further, Mikael on this thread has said he wants the WAN interface to only acquire a link-local but the CPE Router spawn an Loopback interface to which a global IPv6 address is assigned - we have already said in our draft this Loopback interface is optional and your deployment can ignore using it. I'd also like to point out that the configuration required by Mikael is essentially the same as assigning a global IPv6 address to the WAN interface.

Yes, there was a reason why we didn't add text in the Numbered model to say that the global IPv6 address for the WAN interface may be assigned from the IA_PD. We wanted to be careful about it. Here is an example.  The IA_PD obtained by the CPE Router is a /56. The CPE Router sub-delegates this prefix to a /64 for the LAN interface(s). So if a naïve implementation picked a global address for the WAN from the /64, then the WAN and the LAN are in the same IPv6 subnet - that's wrong because the WAN and LAN interface(s) are physically different network segments for the CPE Router and hence they must have different subnets to route traffic between them. What one has to do is pick a global address for the WAN interface from the /56 IA_PD. We can add new text to the Numbered model to cover your suggestion.

As for your other question in another email, no, I haven't seen anyone settle on what prefix length to dole out in the IA_PD - meaning /56 or /48 or what have you. That is why we have stayed away from specifying any prefix length in our draft.

Thanks for the mention of other "health" check mechanisms. At least when the CPE Router is embedded in a cable or DSL modem, I am sure the two broadband deployments have their own heartbeat between CMTS and cable modem or DSLAM and the DSL modem. Personally I don't like an ICMPv6 mechanism because it susceptible to attacks.

Hemant

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, July 17, 2008 5:11 PM
To: Hemant Singh (shemant); Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

I'm sorry to have caused you to think that I didn't want a global IP address on the WAN interface! What I meant to express, was that I didn't think a global IP address needed to be provided via SLAAC or stateful DHCPv6, but that it could be taken from the prefix. The definition of "Numbered Model" is very specific to getting the global address via SLAAC or stateful DHCPv6, and not any other way. So either the "Numbered Model" should also allow the global address to come from the prefix (especially if none comes from SLAAC or stateful DHCPv6), or the "Unnumbered Model" needs to mention that the WAN interface gets a global address from the prefix. I'm fine either way.

Yes, the WAN interface absolutely *must* have a global IP address that it uses for sending and receiving IP messages, as far as I'm concerned.

The "health" of the connection can be determined in a variety of ways.
PPP has messages for testing the PPP connection. I forget what the access network uses in IPv4. I know that inside the home we use ARP (for
IPv4) to test whether the device is still there. There are also PHY and
L2 layer tests to see if those layers are working. I can go ask the access network guys what we do for IP over Ethernet. In addition to these access network methods, our devices have a "heartbeat". They are expected to periodically "phone home" to the TR-069 server. For the health of the device (above and beyond whether the IP connection is up or down), we rely on TR-069. 

FYI: Note that TR-069 is just some remote procedure calls and XML config parameters that run over (SOAP)/HTTPS/TCP/IP. Pretty basic. One big difference between TR-069 and SNMP is that TR-069 requires the CPE to initiate the connection (pull model). The XML config parameters are the analog of SNMP MIBs.
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Thursday, July 17, 2008 2:35 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Let me make sure I understand you. Are you agreeing to that fact that the WAN interface should have a global IPv6 address assigned to it because this is different from what you asked for in the past which was to only assign a link-local address to the WAN interface. Also assume, for the sake of closure to the question, that there is no Loopback interface enabled on the CPE Router - after all, our draft says the Loopback interface is optional.

Further, even I agree with you that it's not wise for a CPE Router to respond to pings. But I appreciate what NTT did in their deployment because how else can one monitor health of the device in the home? The device has to at least rate limit ICMP if the device responds to it.
Section 2.8 of RFC4241 is also not clear when it says "The CPE must return a single IPv6 Echo Reply packet when it receives an ICMPv6 Echo Request packet." What happens if the CPE received another ping req, say,
2 secs later. Will the CPE reply? If yes, then I can launch a ping attack on this CPE sending one pings per x secs and the CPE keeps replying. That is why I mentioned rate limiting.

Hemant

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Thursday, July 17, 2008 1:47 PM
To: Hemant Singh (shemant); Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

I've looked over RFC4241. I think it accurately describes what needs to happen in a generic PPPoE environment -- except the section "2.8.
Connectivity Monitoring". We do not currently require CPE routers to respond to ICMP echo requests. It's even an option in some of our routers for customers to disable responses to unsolicited ICMP messages.
And we still don't have something called a "loopback interface". I also don't think we intend to provide a /48 in this mass market environment.
Probably the smallest prefix would be a /56. I haven't seen any ARIN policy relating to required echo support, especially for an end customer with a /56.

But I'm starting to wonder if we may just be experiencing another terminology problem, with "loopback interface". 

That is, I definitely agree that all CPE routers need to have a global address that can initiate and receive traffic to and from the Internet (over each logical WAN interface -- at the link layer or over PPP). I think this address can easily come from the prefix, and doesn't have to be from SLAAC or stateful DHCPv6. But it definitely needs to exist. The CPE router must be able to act as a host device to the WAN.

Clearly, there will be a link-local IP address on that WAN (link layer or PPP) interface. There may be a global IP address assigned by SLAAC or stateful DHCPv6. If there is, I think it would be useful to think about when the device might use or respond to messages to that global address, vs. global addresses it gives itself from the prefix. My preference would be to always use the prefix address for sending messages, by default (that is, unless configured to do otherwise). Incoming traffic to the SLAAC/DHCPv6 address might be blocked, by default (unless configured otherwise). Unless the device doesn't get a prefix; then it will need to use the SLAAC/DHCPv6 address.

I also think it's not a bad idea for the CPE router to keep the /64 for itself that equates to the prefix it's given followed by zeroes, to get to 64 bits (which is my attempt at trying to generically describe what I think RFC4241 section 2.8 is saying). I think it's fine for the CPE router to be able to respond to echo requests to that /64, if that function (responding to echo requests from the WAN) is enabled.
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 7:10 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Did you get a chance to look at our -02 draft and its reference to RFC4241? Please read RFC4241 to see what has NTT done in Japan to their ADSL IPv6 services.

Thanks.

Hemant 

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 5:34 PM
To: Hemant Singh (shemant); Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

I would prefer if no statements were made as to number of physical WAN interfaces. We have some bonded DSL interfaces that have 2 physical interfaces that are bonded together at either the ATM or Ethernet layer.
There are 2 physical WAN interfaces, but from the perspective of the IP portion of the access network, there is only one "logical" WAN interface on the router.

I really would prefer to describe the behavior of a single link layer
(L2) interface, rather than make any mention of physical interfaces (quantity, PHY, jack, or otherwise). I agree with your statement that this document's functionality needs to be abstracted from the physical.
I really, really agree.
Barbara

-----Original Message-----
From: Hemant Singh (shemant) [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:51 PM
To: Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Barbara,

Thanks for this email. For the purposes of description of behavior of a CPE Router, all we are asking for is how many physical WAN interface ports will the CPE Router have? We have recommended one. We could care less about any other physical layer behavior. We are defining routing behavior that sits abstracted from link or physical layers. Where a layer 2 affects IPv6 ND protocol behavior, we mention it - like PPP address acquisition does not perform DAD. 

Hemant

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 4:17 PM
To: Antonio Querubin; Hemant Singh (shemant)
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

I don't understand the relevance of mentioning PHY interfaces, PHY modems, or pure Ethernet switches, in a document about IPv6 behavior of CPE routers. A physical instantiation of a CPE router may indeed contain a PHY modem and Ethernet switch, but I don't see why that's relevant or needs to be called out in this document.

I don't see any functionality described in this draft that changes based on the link layer or below. Certainly not if the link layer is Ethernet.

I know that there do exist WAN PHY interfaces that do not have the IP running over either  Ethernet link layer or PPP. Such IP interfaces will either exhibit the same behavior as described in this document, or they won't. If they do, that can be mentioned. If they don't, but have mass market relevance, it can be described how they differ. The WAN interface as an Ethernet link layer interface will cover all mass market retail routers, and the vast majority of DSL modem/routers. I can't speak for DOCSIS or UMTS, since I don't know those protocol stacks very well. If they don't use Ethernet for their link layers, do they have some other link layer that is similar to Ethernet? Is there any reason why that link layer shouldn't be considered the "WAN interface"?
Barbara

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]]
Sent: Tuesday, July 15, 2008 2:00 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

to mean different things depending on whether the layer 2 modem is integrated into the CPE router.  For discussion purposes, in a general network configuration where all the components are separate you'll have:

                     PCs
                      |
                      |
                      |

devices (E) behind it, the CPE router being discussed potentially encompasses functionality of devices A, B, C, and D.

links the modem to the internal router device C may or may not be accessible to the consumer via external physical ports.  If they are physically accessible, they need a different name than "WAN" if "WAN" is

defined to be 1 above.

However these multiple definitions of WAN interfaces are confusing, hence my earlier suggestion of using different names for the modem-router interface and the access provider interface.

WAN interface - a network interface on the CPE Router that is used to connect the router to the access network of the Service Provider.  When a CPE Router is embedded in a device that connects to the service provider

via a non-ethernet connection, this interface is the logical interface that connects the internal router to the internal bridge.  Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.

SPA (service provider access) interface - a non-ethernet physical network interface that is bridged to the WAN interface and directly connects to the access network of the Service Provider.

But if you want to keep the definition of WAN tightly coupled with the physical external port then something like this might be more suitable:

WAN interface - a network interface on the CPE Router that is used to connect the router directly to the access network of the Service Provider. 
When a CPE Router is embedded in a device that connects to the service provider via a non-ethernet connection, this physical interface is bridged to the router via an internal modem.  Some devices which can have an embedded CPE router are: a cable or DSL modem, or a cellular telephone, etc.

WANEA (WAN Ethernet Access) interface - an optional ethernet interface that is bridged to the WAN interface and provides additional direct access to the Service Provider network.

Antonio Querubin
whois:  AQ7-ARIN

*****

*****

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 17:51:53 -0400

Fred,

I just replied to Barbara. Please read that email. What you are saying
is what we and others also have been harking at. A router can send
packets sourced from any of physical or virtual interfaces.

I have told Shin from NTT and Barbara from AT&T that if they want a
global IPv6 address on the WAN interface - fine. Then we have also told
them they don't have to spawn the optional Loopback interface if they
don't want to. 

Then I told Mikael, that for his purpose, his WAN interface only acquire
a link-local and the CPE Router spawn a Loopback interface that will be
assigned a global IPv6 address. Then the CPE Router can source packets
with the Loopback interface global address when the router needs to.

Hemant 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, July 17, 2008 5:43 PM
To: Hemant Singh (shemant); Stark, Barbara; Antonio Querubin
Cc: [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

>Loopback interface is optional.

I don't understand this. If it is a router, it follows the weak end
system model and it can source packets from addresses assigned to any of
its interfaces, including virtual interfaces like a loopback. I do not
see a requirement for assignment of a non-link-local IPv6 address on the
WAN interface.

Fred

>policy relating to required echo support, especially for an end 
>customer with a /56.
>

>or PPP) interface. There may be a global IP address assigned by SLAAC 
>or stateful DHCPv6. If there is, I think it would be useful to think 
>about when the device might use or respond to messages to that global 
>address, vs. global addresses it gives itself from the prefix. My 
>preference would be to always use the prefix address for sending 
>messages, by default (that is, unless configured to do otherwise). 
>Incoming traffic to the SLAAC/DHCPv6 address might be blocked, by 
>default (unless configured otherwise). Unless the device doesn't get a 
>prefix; then it will need to use the SLAAC/DHCPv6 address.
>

>to 64 bits (which is my attempt at trying to generically describe what 
>I think RFC4241 section 2.8 is saying). I think it's fine for the CPE 

>portion of the access network, there is only one "logical" WAN 
>interface on the router.
>

>CPE routers. A physical instantiation of a CPE router may indeed 
>contain a PHY modem and Ethernet switch, but I don't see why that's 
>relevant or needs to be called out in this document.
>
>I don't see any functionality described in this draft that changes 
>based on the link layer or below. Certainly not if the link layer is 
>Ethernet.
>
>running over either  Ethernet link layer or PPP. Such IP interfaces 
>will either exhibit the same behavior as described in this document, or

>they won't. If they do, that can be mentioned. If they don't, but have 
>mass market relevance, it can be described how they differ. The WAN 
>interface as an Ethernet link layer interface will cover all mass 
>market retail routers, and the vast majority of DSL modem/routers. I 
>can't speak for DOCSIS or UMTS, since I don't know those protocol 
>stacks very well. If they don't use Ethernet for their link layers, do 
>they have some other link layer that is similar to Ethernet? Is there 
>any reason why that link layer shouldn't be considered the "WAN 
>interface"?
>Barbara
>

>information by persons or entities other than the intended recipient is

>prohibited. If you received this in error, please contact the sender 
>and delete the material from all computers. GA621
>
>
>
>*****
>
>information by persons or entities other than the intended recipient is

>prohibited. If you received this in error, please contact the sender 
>and delete the material from all computers. GA622
>
>
>
>

---

From: "Ole Troan" <[email-masked]>
Date: Fri, 18 Jul 2008 00:29:42 +0200

> Yes, there was a reason why we didn't add text in the Numbered model to say that the global IPv6 address for the WAN interface may be assigned from the IA_PD. We wanted to be careful about it. Here…

this model is not supported by RFC3633.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 18:35:33 -0400

OK, then we'll hold off Barbara's suggestion to add anything to the Numbered section. If DSL folks want to push their proposal in this area, they can work with the authors of RFC3633.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Thursday, July 17, 2008 6:30 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; Antonio Querubin; [email-masked]
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 18:50:28 -0400

Ole,

It does help us if you can point to text in RFC3633 that prohibits the behavior that is being asked by some DSL folks.

Thanks.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Thursday, July 17, 2008 6:30 PM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; Antonio Querubin; [email-masked]
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

/ot

---

From: "Ole Troan" <[email-masked]>
Date: Fri, 18 Jul 2008 01:05:59 +0200

Hemant,

> It does help us if you can point to text in RFC3633 that prohibits the behavior that is being asked by some DSL folks.

section 12.1:

   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Jul 2008 19:09:44 -0400

Ole,

Thanks very much! I kind of figured it would be like this since my
example to Barbara said it would be wrong for a router to have two
disparate segments to be configured with same subnet.

Barbara and anyone else, you will have to get a global IPv6 address for
the WAN interface via SLAAC or DHCPv6 and then obtain the IA_PD via
DHCPv6 or stateless DHCPv6.

Hemant 

-----Original Message-----
Sent: Thursday, July 17, 2008 7:06 PM

Hemant,

> It does help us if you can point to text in RFC3633 that prohibits the
behavior that is being asked by some DSL folks.

section 12.1:

/ot

---

From: David Miles <[email-masked]>
Date: Fri, 18 Jul 2008 14:16:21 +1000

Hemant and Wes,

Some comments on draft-02:
- The un-numbered  model doesn't require a loopback interface
- ULA addresses generation per RFC4193 may not be appropriate for CPE  
as it requires time of day and is a one-time algorithm. I think we may  
need to suggest a new random algorithm that is consistent with the one  
in RFC 4193 and does not require time of day. We should also point out  
that a ULA prefix should be consistent across reloads and there must  
be some method by which the user can regenerate or otherwise specify  
their desired ULA prefix. Finally ULA is a 48-bit prefix.
- I think we should add a line that says traffic with a ULA source  
address should not be forwarded out the WAN interface, rather than  
noting you could use user-configured ACL.
- Seeing you mention DAD on the WAN interface, you may also want to  
add joining the solicited-node MC group via MLD per RFC 4861/2.
- Suggest you use RIPng terminology rather than RIPv6
- The IPv6 over PPP and softwire sections makes no mention of WAN  
interface address assignment other than IPv6CP (interface-ID). Should  
we support both numbered and unnumbered models on PPP links?
- Section 7: IPv6 Data forwarding should reference the Default Routers  
List and the creation of the default route based on this. As you've  
covered off cascading routers we also need to consider how to route  
traffic to them (assuming they will in turn populate their default  
router list with the root CPE). This suggests the DHCPv6 server in the  
CPE must be able to trigger route updates based on active leases.

I think we need a new section that describes CPE behaviour on reload/ 
WAN up, thoughts below:
-----
5.4 Prefix Delegation Rebinding
Whenever the CPE WAN link changes state, addresses passed through  
DHCPv6 must be revalidated. Conditions that should trigger a Rebind  
include:
- When the CPE reboots
- When the CPE WAN interface transitions to an up state

Prior to completing a Rebind, the CPE should continue to use addresses  
and lifetimes previously assigned to its LAN interface(s) that are  
derived from IA_PD Prefix options. These may be subsequently  
invalidated through the Rebind process.

On reload, a routing CPE may not be able to validate any IA_PD Prefix  
option lifetimes. Certain parameters must be stored in persistent  
memory to avoid a situation where hosts in the LAN segments consider  
previously advertised prefixes valid that the CPE does not know of or  
that may not be permitted by the upstream ISP.
These persistent parameters are:
- DHCPv6 PD
	- IAID
	- Prefix Options
- A register of subnets assigned to each interface with associated  
IAID, IA_PD Prefix option and AdvPrefixList.
- Interface address assignments and lifetimes

The CPE MUST NOT advertise any RA PIO for prefixes derived from IA_PD  
Prefix Options until the prefixes have been validated through a DHCP  
Rebind message exchange.

Once the WAN interface initialises, the reloading CPE SHOULD issue a  
DHCPv6-PD Rebind message, including the stored IAID and Prefix Options  
in the message. The DHCP Reply message will indicate whether the  
prefixes are valid (the valid lifetime is > 0) or invalid (the valid  
lifetime is 0). If there is no reply within CNF_MAX_RD [RFC 3315] the  
CPE MUST initiate DHCPv6 Address Acquisition. It should continue to  
use addresses and lifetimes previously assigned to its LAN interface(s).

For each invalid prefix, the CPE MUST transmit unsolicited RA to LAN  
segments that contain PIO with the invalid prefix and the lifetime set  
to zero to immediately invalidate these addresses from hosts on the  
LAN. The CPE MUST then initialise DHCPv6 Address Acquisition.
For each valid prefix, the CPE MUST transmit unsolicited RA to LAN  
segments that contain PIO with the valid prefix and lifetimes set to  
the values is the DHCP Reply IA_PD Prefix option.

-----
- I'd suggest text in the DHCPv6 Address Acquisition section that  
clarifies IA_PD prefix options received by the CPE are an explicit  
list of valid prefixes. All prefixes in the CPE AdvPrefixList that  
originated from previous IA_PD and that are not contained in the DHCP- 
PD Reply MUST be immediately expired. This ensures a host will not try  
an communicate through the ISP with a invalid source address. I'm not  
sure what we should do in the scenario where DHCPv6 Address  
Acquisitions fails (ie, we get a response but no IA_PD Options) but I  
would lean to doing nothing (ie, dont expire prefixes but do not send  
any PIO, let the lifetime age away)  as we are not going to forward  
anyway.

- Some comments on the Unnumbered model with suggested text:

From:
5.3.2. Unnumbered Model
When the CPE router is configured for Unnumbered model, after the WAN  
and Loopback interfaces have acquired a link-local address, the  
Loopback interface initiates SLAAC or stateful DHCPv6 to obtain IA_PD  
option and other configuration information. On receiving the DHCPv6  
REPLY with IA_PD option, the CPE Router sub-delegates one global IPv6  
address from the IA_PD option to the Loopback interface.
At any instance in time of the CPE Router operation, the router does  
not forward any traffic between its WAN and LAN interface(s) if the  
router has not completed IPv6 provisioning process that involves the  
acquisition of a global IPv6 address by the WAN or loopback interface  
and the acquisition of a global or Unique Local Address (ULA) by the  
LAN interface(s).
---
To:
5.3.2. Unnumbered Model
In the unnumbered model the WAN interface will not acquire an  
interface address through SLAAC or DHCPv6. When the CPE router is  
configured for Unnumbered model and after interface initialisation,  
the WAN interface initiates DHCPv6 to obtain IA_PD option and other  
configuration information.

5.3.3. Both Models
  On receiving the DHCPv6 REPLY with a IA_PD option, the CPE Router  
assigns a /64 prefix from within the bounds of the IA_PD Prefix Option  
to all interfaces except the WAN interface. The interface addresses  
are constructed using the /64 prefix and using EUI-64 on each  
interface for the Interface-ID portion of the address.
At any instance in time of the CPE Router operation, the router does  
not forward any traffic between its WAN and LAN interface(s) if the  
router has not completed IPv6 provisioning process that involves the  
acquisition or rebinding of addresses via DHCPv6-PD.

Cheers,

-David

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 18 Jul 2008 07:59:51 -0400

What is the reason for this prohibition? 
Barbara 

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

Hemant,

section 12.1:

/ot

*****

---

From: "Ole Troan" <[email-masked]>
Date: Fri, 18 Jul 2008 14:49:12 +0200

> What is the reason for this prohibition?

let me see if I can recall the arguments at the time:

- the model of prefix delegation in 3633 is strictly hierarchical and
you delegate a prefix typically across an administrative boundary
  the upstream link (link between RR and DR) is managed by the DR
- there are already two mechanisms for address assignment, PD is for
prefix delegation not address assignment. if the delegated prefix
  was subnetted also on the upstream, would the RR send RA's for example?
- the DR will consider the prefix off-link and not use ND for address
resolution, while the RR thinks the prefix is on-link.

what problem are you trying to solve? if you wish to avoid using a
separate /64 for the upstream link, then there is a solution for that
in the draft I believe. (no global address on the upstream link, use
of a loopback interface with an address from the delegated prefix for
management purposes).

cheers,
Ole

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 18 Jul 2008 09:32:28 -0400

Yes, I was trying to avoid use of (and the access network having to know
routing for) addresses in a different subnet. Before I drop this notion,
let me describe a little better what I need a global address for:

The device that physically includes the CPE router needs to be able to
*initiate* traffic to global addresses on the upstream for the following
purposes:
1. SIP client (SIP registration, SIP invite, etc.); SIP server cannot be
assumed to be "known" to the access network -- it's just another
destination on the Internet
2. various tests, including echo requests, traceroute, http file upload
and download for throughput testing, to destinations on the Internet
3. TR-069 remote procedure calls (running over HTTPS/TCP/IP) for remote
management; the TR-069 server cannot be assumed to be within some sort
of "management domain" of the access network -- it should be thought of
as just another destination on the Internet

In addition, it needs to be able to *receive* incoming traffic:
1. responses to all of the above
2. SIP client receives SIP invites
3. HTTP server can be temporarily enabled (by the customer) to allow the
help desk to troubleshoot by using the device's http UI (of course,
using https); help desk is somewhere out on the Internet, and cannot be
assumed to be able to come in through a controlled part of the access
network.

I don't think these functions are appropriate for something that's
described as a "loopback interface for management purposes". But since I
really don't understand what that loopback interface is, I'd appreciate
others' opinions. Are there other options, or should I just give up and
get a global address from SLAAC/stateful DHCPv6?
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Friday, July 18, 2008 8:49 AM
To: Stark, Barbara
Cc: Hemant Singh (shemant); Antonio Querubin; [email-masked]
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

  was subnetted also on the upstream, would the RR send RA's for
example?

cheers,
Ole

to which it is addressed and may contain confidential, proprietary,
and/or privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon this information
by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the
material from all computers. GA623

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 18 Jul 2008 05:57:23 -1000 (HST)

I wonder, for those who feel a loopback interface is important, is that 
because you want the CPE router to be pingable regardless of any PHY 
interface status?  If that's so, since the document's focus is on router 
behaviour, perhaps it is this behaviour should be explicitly mentioned.

Section 5, paragraph 1 states 'optional Loopback network interface, facing 
the Service Provider upstream, which initiates stateless DHCPv6'.  A 
loopback interface doesn't really 'face' any direction.  You might want to 
change the wording to something along the lines of 'optional Loopback 
network interface initiates a DHCPv6 request toward the upstream SP'

Also I notice in the same paragraph, "recommend the CPE Router WAN 
interface acquire its global IPv6 address using stateful DHCPv6 for 
administrative control of the router".  This makes it sound like DHCP is 
recommended for administrative control where I think you mean the global 
address is recommended for administrative control and provisioning of 
proxied services to the downstream devices.  Why not just say "recommend 
the CPE Router acquire a global IPv6 address for administrative control 
..."

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 18 Jul 2008 12:32:32 -0400

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 11:57 AM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

interface status?  

<hs> 
That is one reason senior (savvy) folks like Remi on this mailer gave.
The other reason is equally critical. Some folks requested they only
wanted to assign a link-local to their WAN interface and use a Loopback
interface to assign a global IPv6 address to. Since the device is a
router, spawning any virtual interface on the router is no big deal for
us. We said fine. Then as Ole pointed out today, the Loopback interface
is also a solution for folks like AT&T who want to assign a global
address to the "WAN" interface from the IA_PD that was doled out by the
SP. As Ole said, RFC3633 prevents a RR like the CPE Router to assign any
address from the IA_PD to an interface that the DHCPv6 REPLY ingressed
on. Any DHCPv6 REPLY has to get to the CPE Router via the physical WAN
interface. The Loopback interface gets around this restriction of
RFC3633. However, if AT&T doesn't like using a virtual interface like
the Loopback interface, then I said they have cannot assign an global
address to the WAN interface from the IA_PD the WAN interface gets doled
out. 
</hs>

If that's so, since the document's focus is on router behaviour, perhaps
it is this behaviour should be explicitly mentioned.

Section 5, paragraph 1 states 'optional Loopback network interface,
facing the Service Provider upstream, which initiates stateless DHCPv6'.
A loopback interface doesn't really 'face' any direction.  You might
want to change the wording to something along the lines of 'optional
Loopback network interface initiates a DHCPv6 request toward the
upstream SP'

<hs>
I agree with you. My intent was to only mean that this interface
initiates any address acquisition to the SP. Will take your suggestion.
</hs>

<hs>
Ah, no we don't mean what you suggested with your text. What we mean by
administrative control is that if one uses DHCPv6 then the address
acquisition by any downstream client is known to the Sap's provisioning
servers like the DHCPv6 server and also a backend provisioning systems
(BPS) that serves multiple DHCPv6 servers. If clients acquire IPv6
address using SLAAC, then only the SP router is aware of these clients -
we will need some protocol to run between the SP aggregation router and
the BPS to inform about clients. Cable IPv6 standards have prohibit a
cable modem to initiate SLAAC and mandate that the cable modem initiate
stateful DHCPv6 for address acquisition. This mandate is similar to the
administrative control we are talking about.
</hs>

Hemant

Antonio Querubin
whois:  AQ7-ARIN

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 13:43:28 +0200

> Provider independence.

Cheaper gasoline prices are also a motivation for NAT.

It of course helps if the tool you use actually achieves the intended  
purpose. If we make that a requirement both our examples are out.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 13:56:19 +0200

On 4 jul 2008, at 12:51, [email-masked] wrote:

>> Yes, I realise this, but I want my native IPv6 service offering to  
>> require a "router" class device, even if it means that this  
>> "router" only forwards traffic logically between the WAN link-local  
>> interface and it's internal loopback address (DHCPv6-PD assigned  
>> space).

> Then I suspect you will be greatly disappointed as I do not see most  
> of the devices that will be using IPv6 in the future fitting into  
> this category. Cellular devices outnumber PCs today, and unless you  
> plan to stretch the definition of CPE Router to include the ones at  
> cell sites then you will find that more devices are not behind a CPE  
> router than those that are. Look at the past 5 year trend to mobile  
> internet (Cellular, WiMAX, etc.), RFIDs, Automotive and traffic  
> systems, etc. These devices do not see a device that would fit into  
> this document even though they eventually are served by a router.

The problem is that for hosts that connect to the IPv6 internet over  
ethernet or wifi, we have a widely implemented attachment model:  
router advertisements for a default gateway and on-link prefixes,  
router advertisements for address configuration, optionally DHCPv6 for  
address configuration and/or other config, and hopefully in the future  
router advertisements for DNS configuration. Except for the DNS stuff  
this works well.

The problem is that the service that comes out of the wall usually  
doesn't provide this. Now we could tell the ISPs to add a box to  
provide all of this, but it turns out that ISPs like it when they can  
buy boxes with well-defined functionality from different vendors.  
That's why we're trying to standardize all of this.

All these other systems that you mention use other attachment models,  
which are standardized elsewhere. (Inside or outside of the IETF.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 14:00:40 +0200

On 4 jul 2008, at 17:37, David Conrad wrote:

> Because renumbering IPv6 prefixes will not be transparent, there  
> will be a market for NATv6.

This is such nonsense. I wish you would stop spewing it.

NAT gives you stable internal addresses, which may be useful for some  
stuff, but it won't help you much when you need to renumber because  
the problem there is the addresses that external entities see.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 14:05:46 +0200

On 4 jul 2008, at 15:06, <[email-masked]> <[email-masked] 
 > wrote:

> to verify this right now.

No, that requirement went the way of the dodos in IPv6.

Does this system give the subscriber more than just one /64? If not,  
the phone needs to be a bridge and the service provider will see more  
individual addresses.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 14:15:13 +0200

On 8 jul 2008, at 20:19, Stark, Barbara wrote:

> default with IPv6, as well.

Wouldn't it be better if this could be provisioned automatically?

> It should be pretty apparent if the access network is giving it a  

Agree.

> loopback interface just because it doesn't get a global IP address.

Also agree.

> As a default, we believe

"Real" routers don't answer pings for addresses on interfaces that are  
down. So if there's nothing connected to the ethernet, you wouldn't be  
able to ping.

Of course we can specify the opposite behavior.

> loopback network interfaces with SNMP.

In the router world it's normal to have loopback interfaces with  
global addresses in order to have an address that can be used for  
management, but also for stuff like BGP.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 14:24:45 +0200

On 16 jul 2008, at 1:54, Hemant Singh (shemant) wrote:

> how is RPF going to work?

If you run unicast RPF (uRPF, RPF itself is for multicast) on the ISP  
router then this whill work regardless of the interface the CPE uses  
to source packets because all the address space delegated to the user  
is obviously routed towards the CPE so it will pass the uRPF check.

> RPF needs global IPv6 addresses.

Link local addresses can't be forwarded by routers anyway, so uRPF and  
link locals are orthogonal.

Where is the packet with a link local source address supposed to go to?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 14:28:50 +0200

On 17 jul 2008, at 20:35, Hemant Singh (shemant) wrote:

> respond to pings.

It's a router so it must generate numerous other ICMP packets in  
response to certain incoming packets. So not responding to pings  
doesn't buy you anything.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 14:45:25 +0200

(Sorry about the large number of messages...)

> it uses for sending and receiving IP messages, as far as I'm  

Huh? Didn't you say the exact opposite earlier?

There three questions:

1. Should the CPE have a global address that it can use to send  
outgoing packets on the WAN interface

2. Should it be an option for the ISP to not provide address  
configuration over the WAN link (obviously they must do DHCPv6 PD)

3. If both 1 and 2, then what? Options:
3a: use a loopback interface and take a subnet from the PD prefix  
(even if it's only a /128, but that still makes a /64 unusable for  
anything else)
3b: use an address from a LAN interface (issue with usability of this  
address if LAN interface is down)
3c: take a subnet from the PD prefix (even if it's only a /128) and  
use it on the WAN interface

Note that 1 MUST be answered with YES if there is the possibility that  
a LAN interface has a smaller MTU than the WAN interface in order to  
get PMTUD to work, and SHOULD be yes for the purpose of other ICMPv6  
messages.

3b and 3c have the issue that they eat up address space, so if the ISP  
only provides a /64 you're in trouble. 3c also has the issue that it  
doesn't make much sense because the ISP doesn't know the address is on- 
link.

3b seems to make sense.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 09:45:57 -0400

Also agree. 

<hs> 
Not quite.  The unnumbered model is clearly saying the WAN interface
only acquires on a link-local address.  But the WAN interface of the CPE
Router has got to have a global IPv6 address.  So what choice does the
CPE Router have but to automatically spawn a Loopback interface that
will get assigned a global IPv6 address (using SLAAC, DHCPv6, or one
address from the IA_PD when the Loopback interface uses, say, stateless
DHCPv6 to acquire an IA_PD).
</hs>

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 09:51:20 -0400

The draft clearly says what ICMPv6 errors are returned by the CPE
Router, so it's not like the CPE Router is not responding to any ICMPv6
request. Existing IPv4 routers do have a ping disable feature where the
router is configured to not respond to pings.  I also said on this
thread that if the CPE Router does respond to pings, the CPE Router
needs to rate limit incoming ping reqs.

Hemant 

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Sunday, July 20, 2008 8:29 AM
To: Hemant Singh (shemant)
Cc: Stark, Barbara; Antonio Querubin; [email-masked]
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

It's a router so it must generate numerous other ICMP packets in
response to certain incoming packets. So not responding to pings doesn't
buy you anything.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 10:43:31 -0400

Please see the complete uRPF thread that we discussed on this mailer -
they were emails between July 15 - 16th, 2008.  Here is one piece of
text snipped from my email on the subject of uRPF on July 16th.  I
wasn't talking about any packet with src-addr as link-local.

"I have a spoofed packet with global src-addr input to the WAN interface
of a standalone CPE Router - the destination of this packet is the
global IPv6 address of a LAN interface.  Strict uRPF check will check if
the src-addr is reachable by a path thru the input interface which is
the WAN interface. The WAN interface, which is also a routed port has
only a link-local address.  So how can the global address have a path
thru the WAN interface that is assigned only a link-local address?"

Hemant 

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Sunday, July 20, 2008 8:25 AM
To: Hemant Singh (shemant)
Cc: Ole Troan; Stark, Barbara; [email-masked]; Antonio Querubin
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

> address, how is RPF going to work?

If you run unicast RPF (uRPF, RPF itself is for multicast) on the ISP
router then this whill work regardless of the interface the CPE uses to
source packets because all the address space delegated to the user is
obviously routed towards the CPE so it will pass the uRPF check.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 12:03:01 -0400

David,

Please see in line between <hs> and </hs>. 

-----Original Message-----
From: David Miles [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 12:16 AM
To: Hemant Singh (shemant)
Cc: v6ops WG
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

Hemant and Wes,

<hs>
It does.  You may be behind checking your emails on this thread.  Please
read ample evidence given for this one. 
</hs>

- ULA addresses generation per RFC4193 may not be appropriate for CPE as
it requires time of day and is a one-time algorithm. I think we may need
to suggest a new random algorithm that is consistent with the one in RFC
4193 and does not require time of day. We should also point out that a
ULA prefix should be consistent across reloads and there must be some
method by which the user can regenerate or otherwise specify their
desired ULA prefix. Finally ULA is a 48-bit prefix.

<hs>
Hmm, ULA is restricted to one home, so what are the odds of ULA clashing
for one single home/SOHO premise since number of devices in the home may
be 256 or even 500 or so.  The only way my ULA is visible to my
neighbor's home is if the CPE Router includes a WLAN.  But two different
homes have different wireless SSID, so even then if the ULA clashes with
my neighbor's, it's not a clash.  I do grant folks that fact that both
myself and my neighbor may be lazy people and we both use the default
SSID shipped with the WLAN of the CPE Router.  But anyhow, how many
clients exists in the home that the algorithm in RFC4193 is not good.
For 100 connections, RFC4193 has this probability of collision.

100                4.54*10^-09

</hs>

<hs>
All Internet RFC's mention filtering of ULA traffic at the edge.  In
that vein our use of ACL is appropriate.  Anyhow, this is a minor point
we can look into later.
</hs>

- Seeing you mention DAD on the WAN interface, you may also want to add
joining the solicited-node MC group via MLD per RFC 4861/2.

<hs>
Disagree with the idea.  We mention DAD in the draft only because for
some links like PPP, the draft needs to point out that DAD will not be
invoked for unicast addresses.  Your suggestion is one detail too many.
</hs>

<hs>
Agreed. Thanks.
</hs>

- The IPv6 over PPP and softwire sections makes no mention of WAN
interface address assignment other than IPv6CP (interface-ID). Should we
support both numbered and unnumbered models on PPP links?

<hs>
Yes. PPP links also get their link-local address as per RFC5070.  Then
just like other networks that don't use PPP, even PPP link will use
SLAAC or DHCPv6 to acquire a global IPv6 address.  I have also said, we
need to update the Unnumbered section to also include assigning the
Loopback interface a global IPv6 address from the IA_PD obtained by the
Loopback interface.  I can add such text to the PPP section. 
</hs>

- Section 7: IPv6 Data forwarding should reference the Default Routers
List and the creation of the default route based on this.

<hs>
No.  We will define our router in terms of our own conceptual variables
for routing.  Default Routers List is a ND conceptual variable.  
</hs> 

 As you've covered off cascading routers we also need to consider how to
route traffic to them (assuming they will in turn populate their default
router list with the root CPE). This suggests the DHCPv6 server in the
CPE must be able to trigger route updates based on active leases.

<hs>
Once we say that RIPng may be used in the home, that is enough for
routing information to flow from home's downstream routers to the next
upstream router in the cascade.  We will consider adding text to the
Cascading section to say RIPng may be used in the home.  The DHCPv6
server suggestion is so that the IA_PD can be sub-delegated downstream
in the cascade, not for route updates!

I have snipped out the rest of your email because I will reply to the
snipped lot in another email.  I wanted to get this reply out first.
</hs>

Hemant

---

From: Antonio Querubin <[email-masked]>
Date: Sun, 20 Jul 2008 08:30:10 -1000 (HST)

> needs to rate limit incoming ping reqs.

You mean responses?  The rate limiting should be optional.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 14:34:12 -0400

No, I meant incoming ping reqs to the CPE Router's WAN interface. We
have seen home networks getting attacked with pings from the WAN in
cable deployments.  As one may note, we don't discuss any throttling of
ping reqs or responses into/from the CPE Router.  We are going to think
about it and see what do mention about throttling for the CPE Router.

Hemant 

-----Original Message-----
From: Antonio Querubin [mailto:[email-masked]] 
Sent: Sunday, July 20, 2008 2:30 PM
To: Hemant Singh (shemant)
Cc: Iljitsch van Beijnum; Stark, Barbara; [email-masked]
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Sun, 20 Jul 2008 08:53:26 -1000 (HST)

> thru the WAN interface that is assigned only a link-local address?"

The default route has to go somewhere.  Regardless of whether the single
WAN interface acts like a point-to-point link or is multi-access, it's
still the one ingress point from SP to the customer.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Sun, 20 Jul 2008 09:02:36 -1000 (HST)

> No, I meant incoming ping reqs to the CPE Router's WAN interface. We
               ^^^^^^^^
> about it and see what do mention about throttling for the CPE Router.

I'm confused.  How does one rate-limit incoming requests on the WAN side 
when that's not under the control of the device?  You can only rate-limit 
what you originate or forward, regardless of whether it's destination is 
internal or external.

whois:  AQ7-ARIN

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2008 21:38:34 +0200

> <hs>

Would you PLEASE use normal quoting techniques? Reading email costs  
enough time as it is without everyone doing stuff in their own  
particular way so automation and habits don't work.

> Router has got to have a global IPv6 address.

You are being extremely imprecise. That is one of the reasons your  
draft is in such bad shape.

The INTERFACE doesn't need a global address, but the ROUTER does.

> So what choice does the
> will get assigned a global IPv6 address

When you need to create a packet, use a source address from another  
interface that you have, i.e. a LAN interface. I believe this is  
explained in the base IPv6 specs. Or ask within your company about the  
behavior of "ipv6 unnumbered ..."

> (using SLAAC,

Creating addresses using stateless autoconfig on an interface  
different than the one where the RAs were received is very wrong.

> DHCPv6

Using DHCPv6 address configuration on a router makes no sense in my  
opinion.

> stateless DHCPv6 to acquire an IA_PD).

I don't think prefix delegation is possible in the stateless version  
of DHCPv6.

On 20 jul 2008, at 15:51, Hemant Singh (shemant) wrote:

> request.

Good.

> Existing IPv4 routers do have a ping disable feature where the
> router is configured to not respond to pings.

You are again using imprecise terminology. What you mean is IPv4 CPEs  
with NAT functionality. That has little to do with routing. For IPv6,  
CPEs do have to be real routers and conform to normal router behavior  
unless we specify exceptions.

It is of course allowed to not return echo replies.

However, since the router MUST generate other ICMPv6 messages under  
other circumstances, not replying to pings doesn't make the router  
invisible so there is little point in not returning ping replies.

> I also said on this

You say that you want to rate limit INCOMING pings. (Which is useless  
anyway because the LAN bandwidth is much higher than the WAN  
bandwdith.) If you want to do this, it makes no sense to tie that to  
whether or not ping replies are sent. For the router itself this is a  
non-issue because the IPv6 specs mandate that ICMPv6 messages are rate  
limited anyway.

On 20 jul 2008, at 16:43, Hemant Singh (shemant) wrote:

> they were emails between July 15 - 16th, 2008.

I read it earlier today. It didn't make much sense to me. But now it  
occurs to me that you actually want to run uRPF on the CPE itself. I  
don't see how that's useful. What you want to do is filter out  
outgoing packets on the WAN interface if they don't have a source  
address that is either in the prefix delegated by the ISP or have the  
router's own WAN address as a source address.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 18:53:57 -0400

David,

Here is my response to the rest of your email. Please see in line below
between <hs> and </hs>. 

-----Original Message-----
From: David Miles [mailto:[email-masked]] 
Sent: Friday, July 18, 2008 12:16 AM
To: Hemant Singh (shemant)
Cc: v6ops WG
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

Hemant and Wes,

------- snip ---------------------------

<hs>
WAN up is already described in the document in various sections.  A
reload section may make sense to add to the document.  If I and Wes are
convinced, we'll add such a TBD to a "TBD list" for the document that we
maintain.  For all of our sanities, I will publish this TBD list every
Friday so that everyone is aware what is TBD.  We clearly have ignored
some people's comments and requests because they didn't make sense to
us.  Folks are welcome to contact us if they still want their request to
be kept in our TBD list with give proper justification.  
</hs>

-----

Prior to completing a Rebind, the CPE should continue to use addresses
and lifetimes previously assigned to its LAN interface(s) that are
derived from IA_PD Prefix options. These may be subsequently invalidated
through the Rebind process.

On reload, a routing CPE may not be able to validate any IA_PD Prefix
option lifetimes. Certain parameters must be stored in persistent memory
to avoid a situation where hosts in the LAN segments consider previously
advertised prefixes valid that the CPE does not know of or that may not
be permitted by the upstream ISP.
These persistent parameters are:
- DHCPv6 PD
	- IAID
	- Prefix Options
- A register of subnets assigned to each interface with associated IAID,
IA_PD Prefix option and AdvPrefixList.
- Interface address assignments and lifetimes

Once the WAN interface initialises, the reloading CPE SHOULD issue a
DHCPv6-PD Rebind message, including the stored IAID and Prefix Options
in the message. The DHCP Reply message will indicate whether the
prefixes are valid (the valid lifetime is > 0) or invalid (the valid
lifetime is 0). If there is no reply within CNF_MAX_RD [RFC 3315] the
CPE MUST initiate DHCPv6 Address Acquisition. It should continue to use
addresses and lifetimes previously assigned to its LAN interface(s).

For each invalid prefix, the CPE MUST transmit unsolicited RA to LAN
segments that contain PIO with the invalid prefix and the lifetime set
to zero to immediately invalidate these addresses from hosts on the LAN.
The CPE MUST then initialise DHCPv6 Address Acquisition.
For each valid prefix, the CPE MUST transmit unsolicited RA to LAN
segments that contain PIO with the valid prefix and lifetimes set to the
values is the DHCP Reply IA_PD Prefix option.

-----
- I'd suggest text in the DHCPv6 Address Acquisition section that
clarifies IA_PD prefix options received by the CPE are an explicit list
of valid prefixes. All prefixes in the CPE AdvPrefixList that originated
from previous IA_PD and that are not contained in the DHCP- PD Reply
MUST be immediately expired. 

<hs>
Most of your text above is already mentioned in RFC3633 that is a RFC
referenced in our document.  Like text from section 12.1 of RFC3633
describes some of your text above.  Further, we have added this text to
the end of 2nd paragraph of section 5.5 in our -02 version document
(shown in square brackets below):

[If the IA_PD changes, the CPE Router must reconfigure the LAN
interface(s) with new IPv6 addresses derived from the new IA_PD and then
also renumber the IPv6 ND RA configuration on the LAN interface(s).].

We will add a few more sentences at an appropriate place in our draft
that address your concerns above.
</hs>

This ensures a host will not try an communicate through the ISP with a
invalid source address. I'm not sure what we should do in the scenario
where DHCPv6 Address Acquisitions fails (ie, we get a response but no
IA_PD Options) but I would lean to doing nothing (ie, dont expire
prefixes but do not send any PIO, let the lifetime age away)  as we are
not going to forward anyway.

<hs>
After section 5.3.2, we have a paragraph in the draft that says the
router will not forward any traffic for the case you describe above.
That text is as follows (shown between square brackets): 

[At any instance in time of the CPE Router operation, the router does
not forward any traffic between its WAN and LAN interface(s) if the
router has not completed IPv6 provisioning process that involves the
acquisition of a global IPv6 address by the WAN or Loopback interface
and the acquisition of a global or Unique Local Address (ULA) [RFC4193]
by the LAN interface(s).]. 

Then in section 5.4 of our draft we say (show in square brackets below):

[When the CPE Router processes a DHCPv6 response from the server, if the
response message (e.g. ADVERTISE or REPLY) received does not include an
IA_PD option, or Reconfigure Accept option, then the CPE Router has
failed DHCPv6 address acquisition.].

I don't see why you had to mention your case when we have already
covered the case in the draft?
</hs>

From:
5.3.2. Unnumbered Model
When the CPE router is configured for Unnumbered model, after the WAN
and Loopback interfaces have acquired a link-local address, the Loopback
interface initiates SLAAC or stateful DHCPv6 to obtain IA_PD option and
other configuration information. On receiving the DHCPv6 REPLY with
IA_PD option, the CPE Router sub-delegates one global IPv6 address from
the IA_PD option to the Loopback interface.
At any instance in time of the CPE Router operation, the router does not
forward any traffic between its WAN and LAN interface(s) if the router
has not completed IPv6 provisioning process that involves the
acquisition of a global IPv6 address by the WAN or loopback interface
and the acquisition of a global or Unique Local Address (ULA) by the LAN
interface(s).
---
To:
5.3.2. Unnumbered Model
In the unnumbered model the WAN interface will not acquire an interface
address through SLAAC or DHCPv6. When the CPE router is configured for
Unnumbered model and after interface initialisation, the WAN interface
initiates DHCPv6 to obtain IA_PD option and other configuration
information.

<hs>
No.  We don't want to prohibit the Loopback interface or any virtual
interface on the router from acquiring a global IPv6 address using SLAAC
or DHCPv6.  As I said in an earlier emails, we will add a third option
to the Unnumbered model where the third model will assign a global IPv6
address to the Loopback interface from the IA_PD acquired by the
Loopback interface.  We can also say that this third option is a
preferred option for some SP deployments or any other way that DSL folks
would like us to word the requirement.
</hs>

5.3.3. Both Models
  On receiving the DHCPv6 REPLY with a IA_PD option, the CPE Router
assigns a /64 prefix from within the bounds of the IA_PD Prefix Option
to all interfaces except the WAN interface. The interface addresses are
constructed using the /64 prefix and using EUI-64 on each interface for
the Interface-ID portion of the address.
At any instance in time of the CPE Router operation, the router does not
forward any traffic between its WAN and LAN interface(s) if the router
has not completed IPv6 provisioning process that involves the
acquisition or rebinding of addresses via DHCPv6-PD.

<hs>
The paragraph at the end of section 5.3.2 does apply to both models.
Your suggestion for putting this under a new sub-section makes perfect
sense - thanks!  What the text of the common sub-section is not
agreeable to me.  After we have added our third option to the Unnumbered
section, we will run any new text for the "Both Models" by you take it
from there.
</hs>

Hemant

Cheers,

-David

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 19:20:13 -0400

Folks,

Here is a list of TBD items on our draft from the -02 version that
includes our responses till now.  As I said earlier, till it continues
to make sense, I will publish such a list every Friday (if the list has
changed) till all the requirements in the draft have gestated. 

1. Reference RFC4605 in the mcast section because our proposal is
similar to RFC4605.  Need to give an example
   to Remi to show explicitly how mcast works in the CPE Router. The
example is not planned to be added to the draft. 

2. Add IP addr assignment of global IPv6 addr from IA_PD to the
Unnumbered model (5.3.2) section. Also change some
   text in section 5 for IA_PD and this global address assignment.

3. Change text for Loopback interface that says "facing the WAN" - done.

4. Add to softwire section to track SNAT and dual-lite drafts and each
draft's gross requirements including the
   fact that dual-lite supports v4 in v6 encap and not softwire.

5. Any auto-detection, if possible, for DHCP vs. PPPOE for WAN.

6. Add placeholder for local proxy DNS server to draft to -03 version
and then complete this section in a later version.

7. Section 5.5 needs to add NTP option and any other options to pass to
hosts in the home.

8. For IA_PD addr to be assigned to Loopback, should we suggest
assigning prefix::1 to the WAN interface?

9. Tone down language for LAN hosts doing SLAAC vs. DHCPv6?

10. Add text to PPP section to mention that such links will also acquire
global IPv6 address using
    SLAAC or DHCPv6 or from IA_PD even though the section 5.3 of the
draft already mentions the same fact.
    This TBD makes the PPP section more clear.

11. Section 6, "Cascading of Routers behind the CPE Router" will add
text to say RIPng may be used
    in the home for routing across a cascaded router set in the home.
We have already changed the document
    to use RIPng and not RIPv6.  No other mention of routing for the
home is necessary and out of scope of our document.

12. May make sense to add a Reload section to the draft.  Need to get
back to the mailer on this one.

13. Fold in some text from RFC3633 for verifying of IA_PD prefix across
CPE Router reload, or WAN interface
    bounce.

14. Make a new sub-section called "Both Models" and move text from end
of section 5.3.2 to this new sub-section.
    Text may change for the new sub-section to align with the new
version of the draft.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 21:41:29 -0400

We are NOT adding any uRPF check feature to the CPE Router WAN on LAN
interface(s) nor any ping throttle feature for ping reqs or responses.
These are just topics being discussed.  uRPF was only given as an
example to say why CPE Router cannot work with just a link-local on the
WAN interface.

We want to focus first on getting a complete set of requirements from
DSL folks and then see what does the draft shape out to be.  In our -00
version of the draft, the draft was complete for cable deployment
because cable has completed docsis 3.0 standards for IPv6 as of two
years back and also an embedded CPE Router cable modem standard
completed in May 2007.  

We have clearly said to this mailer early on, that till we get a common
consensus between DSL providers like AT&T, NTT, DSLForum folks like
David Miles, and a Mikael A., nothing in this draft is concrete.  Of
course, I and Wes gave our cable recommendation to the DSL guys in -00
version but they didn't like it.  Our cable recommendation in the -00
version has nothing to do with IA_PD and stateless DHCPv6, or a Loopback
interface, or a WAN interface with only a link-local address.

During the course of -01 and -02 versions we were attempting to fold in
requirements from DSL and that has caused some problems in the draft.
The DSL requirements from NTT, AT&T, and a Mikael have been varied.  You
guessed correctly.  The Loopback interface cannot ask for IA_PD using
stateless DHCPv6 if the Loopback interface hasn't acquired a global IPv6
address.  The RFC for stateless DHCPv6 in RFC3736 clearly says the
following in the Abstract section.

[A node that uses stateless DHCP must have obtained its IPv6 addresses
through some other mechanism, typically stateless address
autoconfiguration.].

So the Loopback solution for DSL guys in our -02 version doesn't look
good even though Mikael A., and David Miles suggested this path to us.
As you can see we are still analyzing the solution and questioning
requirements.  The Loopback interface would need to acquire a global
IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC doesn't
support getting IA_PD).  Also during stateful DHCPv6, the IA_PD is doled
out to the interface and the interface also gets an IA_NA.  Since the
interface already got a global address in the IA_NA, then what's the
point of assigning the interface an IPv6 address out of the IA_PD?  So
will one release the IA_NA, and then configure an address on the
interface from the IA_PD?  I don't like such machinations.  Clearly, the
DSL requirements are not flushed out yet for us.

Also, you can keep arguing about router vs. interface and who's correct
or not.  If the CPE Router needs a global address, the next question
folks will ask is what interface on the CPE Router does the global
address gets assigned to?  We are describing such details.

Also, the virtual Loopback interface is in the same link-local domain as
the WAN interface.  Therefore any RA sent to the WAN interface has to be
also seen by the Loopback interface (CPE Router internals have to take
care of this).  So then it is legal for the Loopback to use the RA seen
by the WAN interface and the proceed to get a global IPv6 address for
the Loopback address using SLAAC or DHCPv6. 

Hemant

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]] 
Sent: Sunday, July 20, 2008 3:39 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

> only acquires on a link-local address.  But the WAN interface of the 
> CPE Router has got to have a global IPv6 address.

You are being extremely imprecise. That is one of the reasons your draft
is in such bad shape.

> (using SLAAC,

Creating addresses using stateless autoconfig on an interface different
than the one where the RAs were received is very wrong.

> stateless DHCPv6 to acquire an IA_PD).

I don't think prefix delegation is possible in the stateless version of
DHCPv6.

Good.

> Existing IPv4 routers do have a ping disable feature where the router 
> is configured to not respond to pings.

I read it earlier today. It didn't make much sense to me. But now it
occurs to me that you actually want to run uRPF on the CPE itself. I
don't see how that's useful. What you want to do is filter out outgoing
packets on the WAN interface if they don't have a source address that is
either in the prefix delegated by the ISP or have the router's own WAN
address as a source address.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 20 Jul 2008 22:00:43 -0400

For Iljitsch van Beijnum related to his question on whether IA_PD could
be asked of by stateless DHCPv6:

Sorry one correction for this statement in the email below. 

"The Loopback interface would need to acquire a global IPv6 address
first using stateful DHCPv6 (a MUST, because SLAAC doesn't support
getting IA_PD).(a MUST, because SLAAC doesn't support getting IA_PD)."

The Loopback interface may acquire the global IPv6 address using SLAAC
and not necessarily DHCPv6.  Then since the Loopback interface does have
a global address, then I believe it is permissible for stateless DHCPv6
to get IA_PD by specifying the IA_PD option in the ORO?  We need to
check if RFC3633 explicitly prohibits asking for IA_PD by stateless
DHCPv6? Ole, what say you - thanks?

Anyhow, the problem still remains that we expire the SLAAC address and
then reassign an address from IA_PD. Same old ugliness.

Hemant  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Sunday, July 20, 2008 9:41 PM
To: Iljitsch van Beijnum
Cc: IPv6 Operations
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Hemant

-----Original Message-----
From: Iljitsch van Beijnum [mailto:[email-masked]]
Sent: Sunday, July 20, 2008 3:39 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Good.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 21 Jul 2008 11:13:40 +0300

>> I'm not sure if the GGSN even configures itself global address from 
>> the prefixes it gives to subscribers (does router have to 
>configure an 
>> address for itself from the prefixes it sends out in RAs?). I was 
>> unable to verify this right now.
>
>Does this system give the subscriber more than just one /64? 
>If not, the phone needs to be a bridge and the service 
>provider will see more individual addresses.

Currently just one /64 per bearer. However, a network provider may
configure phones to use simultaneously more than one bearer (called PDP
contexts or EPS bearers as per 3GPP Release-8). A network provider can
choose to configure separate bearers to be used for Internet and
Intranet accesses. E.g. browser application may be configured to use
bearer that provides only Internet connectivity, while email application
may be configured to use bearer that can be used only to access
Intranet.

There are discussions ongoing about making it possible for phones to get
more prefixes with DHCPv6 PD.

As far as I see, future cellular system could work like this:
- allocate single /64 per bearer (as now)
- phone uses SLAAC to configure an address for itself from this prefix
(as now)
- phone checks (or is preconfigured with required information) whether
the recently attached network supports DHCPv6 PD
-> if YES
	- phone gets more prefixes with DHCPv6 PD, and starts to
advertise them to LAN
-> if NO
	- phone engages ND Proxy

This also gives implementation priority for phones that wish to share
the single "WAN" bearer with other devices: ND proxy support is a must,
while DHCPv6 PD is a should as it is not guaranteed to be available in
all networks the phone may connect to.

This approach has the benefit of using just single bearer between phone
and cellular network, which saves network's resources (when compared to
multiple parallel bearers).

Alternative implementation is to have multiple bearers (=multiple WAN
connections), e.g. one bearer for phone's internal applications, and
different bearer for LAN use. In this approach network allocates one /64
for the phone's own use, and another /64 for the LAN's use (which can be
implemented as a standard dial-up modem like functionality, or as a
bridging solution).

The multiple bearer solution works however only in certain cellular
environments, as there is also a case where a phone is providing IP
connectivity to Bluetooth Personal Area Network: when connected to
cellular network, the phone may have one or more bearers with DHCPv6 PD
or not, but if the phone happens to connect to WLAN hot-spot, it has not
other option than to share the WLAN connection between the internal
applications and the Bluetooth PAN network.

Best regards,

	Teemu

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Mon, 21 Jul 2008 02:46:04 -0700 (PDT)

You say "Also, the virtual Loopback interface is in the same link-local domain as the WAN interface."

I don't understand your architecture. bridge? no bridge?

Can you make a diagram of the WAN side ?

Francois-Xavier

--- On Sun, 7/20/08, Hemant Singh (shemant) <[email-masked]> wrote:

> To: "Iljitsch van Beijnum" <[email-masked]>
> Cc: "IPv6 Operations" <[email-masked]>
> Date: Sunday, July 20, 2008, 9:41 PM
> > Router, so it's not like the CPE Router is not
> responding to any
> > ICMPv6
> > request.
> 
> Good.
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jul 2008 06:34:28 -0400

Assigning a prefix through DHCPv6 is equivalent to assigning an  
address, which is inherently stateful.

Sections 11 and 12 of RFC 3633 specifies that IA_PD options are  
carried in Solicit, Advertise, Request and Reply messages (as part of  
the initial RR<->DR message exchange).

I note that RFC 3633 does not explicitly disallow the inclusion of an  
IA_PD in an Information-Request message (as used in "stateless"  
DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the  
text in RFC 3633 that describes the prefix delegation mechanism is, I  
think, unambiguous in its description of how the IA_PD is used.

- Ralph

On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant) wrote:

> different
> of
> outgoing

---

From: "Ole Troan" <[email-masked]>
Date: Mon, 21 Jul 2008 12:54:19 +0200

Hemant,

> DHCPv6? Ole, what say you - thanks?

no, you cannot use stateless DHCP for prefix delegation.

I don't understand where you are going with this draft. this is all
over the map. several people on this mailing list has tried to correct
your misconceptions, but we don't seem to be getting through...

e.g:
- false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP
IA/PD protocols
- false: you need a global address on the WAN interface for uRPF
- false: loopback interface is required. (it's only purpose is to have
a stable always up management interface).

> then reassign an address from IA_PD. Same old ugliness.

huh? don't understand this.

I would not support this draft to become a working group document.

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 06:56:42 -0400

Ralph,

Thanks for the quick reply.  I too noticed the text related to Solicit
in RFC3633 but that can be misinterpreted to be merely an example
because even a 2-way Rapid Commit DHCPv6 could be used with IA_PD.
Since we don't see a clear MUST NOT from RFC3633 or RFC3736, one may say
IA_PD is fine to use with stateless DHCPv6 as far as the interface has
acquired a global address.  

Hemant

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, July 21, 2008 6:34 AM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Assigning a prefix through DHCPv6 is equivalent to assigning an address,
which is inherently stateful.

Sections 11 and 12 of RFC 3633 specifies that IA_PD options are carried
in Solicit, Advertise, Request and Reply messages (as part of the
initial RR<->DR message exchange).

I note that RFC 3633 does not explicitly disallow the inclusion of an
IA_PD in an Information-Request message (as used in "stateless"  
DHCPv6) or the inclusion of the IA_PD code in an ORO; however, the text
in RFC 3633 that describes the prefix delegation mechanism is, I think,
unambiguous in its description of how the IA_PD is used.

- Ralph

On Jul 20, 2008, at Jul 20, 2008,10:00 PM, Hemant Singh (shemant) wrote:

> For Iljitsch van Beijnum related to his question on whether IA_PD 
> could be asked of by stateless DHCPv6:
>

> and not necessarily DHCPv6.  Then since the Loopback interface does 
> have a global address, then I believe it is permissible for stateless
> DHCPv6

> example to say why CPE Router cannot work with just a link-local on 
> the WAN interface.
>
> DSL folks and then see what does the draft shape out to be.  In our 
> -00 version of the draft, the draft was complete for cable deployment 
> We have clearly said to this mailer early on, that till we get a 
> common consensus between DSL providers like AT&T, NTT, DSLForum folks 
> like David Miles, and a Mikael A., nothing in this draft is concrete.

> Of course, I and Wes gave our cable recommendation to the DSL guys in 
> -00 version but they didn't like it.  Our cable recommendation in the 
> -00 version has nothing to do with IA_PD and stateless DHCPv6, or a 
> Loopback interface, or a WAN interface with only a link-local address.
>
> During the course of -01 and -02 versions we were attempting to fold 
> in requirements from DSL and that has caused some problems in the 
> draft.

> IPv6 address first using stateful DHCPv6 (a MUST, because SLAAC 
> doesn't support getting IA_PD).  Also during stateful DHCPv6, the 
> IA_PD is doled out to the interface and the interface also gets an 
> IA_NA.  Since the interface already got a global address in the IA_NA,

> then what's the point of assigning the interface an IPv6 address out 
> of the IA_PD?  So will one release the IA_NA, and then configure an 
> address on the interface from the IA_PD?  I don't like such 
> machinations.  Clearly, the DSL requirements are not flushed out yet 
> for us.
>
> Also, you can keep arguing about router vs. interface and who's 
> correct or not.  If the CPE Router needs a global address, the next 
> question folks will ask is what interface on the CPE Router does the 
> global address gets assigned to?  We are describing such details.
>
> Also, the virtual Loopback interface is in the same link-local domain 
> as the WAN interface.  Therefore any RA sent to the WAN interface has 
> to be also seen by the Loopback interface (CPE Router internals have 
> to take care of this).  So then it is legal for the Loopback to use 
> the RA seen by the WAN interface and the proceed to get a global IPv6 
> address for the Loopback address using SLAAC or DHCPv6.
>
> Hemant
>
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Jul 2008 07:15:15 -0400

The rapid commit mechanism also uses Solicit and Reply in a two  
message Solicit/Reply message exchange that is still requires per- 
client state maintenance on the part of the server.  Use of rapid  
commit for prefix delegation is unrelated to the use of "stateless"  
DHCPv6 for prefix delegation.

While I agree that there is no explicit exclusion of the use of an  
IA_PD in an Information-Request message (as used in "stateless"  
DHCPv6) or the inclusion of the IA_PD code in an ORO, there has never  
been any confusion in the past about the implementation of prefix  
delegation.  We could write an errata for RFC 3633 if there is  
consensus that such an update would be useful.

- Ralph

On Jul 21, 2008, at Jul 21, 2008,6:56 AM, Hemant Singh (shemant) wrote:

> carried
> text
>>> router

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 07:31:58 -0400

We are not even concerned about the draft being a WG work item.  We have
not even completed requirements for the device.  

> no, you cannot use stateless DHCP for prefix delegation.

Also, if you say IA_PD is forbidden by stateless DHCPv6, please point to
a MUST NOT text in any RFC.

IA/PD protocols

The Loopback interface doesn't face the downstream or the upstream.  You
and I both know RFC3633 has no explicit text that prohibits stateless
DHCPv6 asking for IA_PD as I showed how (using the ORO once an interface
has acquired a global IPv6 address). 

> - false: you need a global address on the WAN interface for uRPF

If you don't see the obvious problem with uRPF with just a link-local
address on the WAN interface, I suggest you go do a test and get back to
us.

DSL folks have asked to support the WAN interface acquiring a link-local
address.  So it is the Loopback interface that acquires a global IPv6
address to source packets to the WAN.  If the Loopback interface is not
spawned, then since the LAN interface has global IPv6 address, one could
say, use the LAN interface global address to source packets to the WAN.
But the CPE Router will not even function if the WAN interface has only
link-local and the LAN interface has a global IPv6 address - see section
4 of 

http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ole Troan
Sent: Monday, July 21, 2008 6:54 AM
To: Hemant Singh (shemant)
Cc: Iljitsch van Beijnum; IPv6 Operations
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Hemant,

> DHCPv6 to get IA_PD by specifying the IA_PD option in the ORO?  We 
> need to check if RFC3633 explicitly prohibits asking for IA_PD by 
> stateless DHCPv6? Ole, what say you - thanks?

I don't understand where you are going with this draft. this is all over
the map. several people on this mailing list has tried to correct your
misconceptions, but we don't seem to be getting through...

e.g:
- false: downstream interfaces (loopback, LAN) can run SLAAC or DHCP
IA/PD protocols
- false: you need a global address on the WAN interface for uRPF
- false: loopback interface is required. (it's only purpose is to have a
stable always up management interface).

/ot

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 07:37:16 -0400

I think errata for RFC3633 makes sense because there is a means in
stateless DHCPv6 via which the stateless client can ask for IA_PD and no
explicit text in RFC3633 to forbid it. This mailer has a few folks
asking stateless DHCPv6 to obtain IA_PD.  Folks will use any tool
available to them. That is why I say, we should shut the door on this
with an errata.

Thanks.

Hemant

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Monday, July 21, 2008 7:15 AM
To: Hemant Singh (shemant)
Cc: Ralph Droms (rdroms); Iljitsch van Beijnum; IPv6 Operations
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

The rapid commit mechanism also uses Solicit and Reply in a two message
Solicit/Reply message exchange that is still requires per- client state
maintenance on the part of the server.  Use of rapid commit for prefix
delegation is unrelated to the use of "stateless"  
DHCPv6 for prefix delegation.

While I agree that there is no explicit exclusion of the use of an IA_PD
in an Information-Request message (as used in "stateless"  
DHCPv6) or the inclusion of the IA_PD code in an ORO, there has never
been any confusion in the past about the implementation of prefix
delegation.  We could write an errata for RFC 3633 if there is consensus
that such an update would be useful.

- Ralph

---

From: "tom.petch" <[email-masked]>
Date: Mon, 21 Jul 2008 14:09:31 +0200

----- Original Message -----
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Hemant Singh (shemant)" <[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>
Sent: Sunday, July 20, 2008 9:38 PM
Subject: Re: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

> particular way so automation and habits don't work.

Iljitsch

I wish that I could but often I cannot; my e-mail client, the one in use in
9x.xx% of the worlds PCs, will indent and > as long as the
Content-Transfer-Encoding is 7bit, as yours is, or 8bit.  But when it is
quoted-printable, as is often the case from mainland Europe, then there are no >
and short of editing them all in by hand myself - thanks but no thanks - I know
of no way to change this; would that I could.

I agree that it is a pain.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 21 Jul 2008 14:19:42 +0200

----- Original Message -----
From: "Antonio Querubin" <[email-masked]>
To: "Hemant Singh (shemant)" <[email-masked]>
Cc: "Stark, Barbara" <[email-masked]>; <[email-masked]>
Sent: Friday, July 18, 2008 5:57 PM
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

> behaviour, perhaps it is this behaviour should be explicitly mentioned.

For me, it is not just pingable but all aspects of control and management.  I
have always thought the term 'loopback' misleading.  I first encountered it with
routing protocols, with the need to have a stable IP address to which to send
updates, even, especially, when an interface was down and so packets could not
be sent to the address of that interface -  and there was never any way of
knowing which interfaces were still up.  I see such a concept, although not
necessarily with the same name, in use with ftp, to download configurations and
code updates; with snmp, for general purpose management; with telnet, ditto;
even with icmp.  Commonly, it is possible to have multiple such addresses, to
split the traffic and security for different applications, but I expect there to
be at least one, whose status is divorced from the physical status of any or all
the interfaces.

I am talking, as you may deduce, of experience with IPv4, not with IPv6, and
appreciate that IPv6 has lots of clever additions, but suspect that the
principle remains, that if an interface goes down, then it will not be possible
to send packets to the address of that interface, and so a virtual interface
address is needed.  I assume that the address must be global although where the
prefix comes from is a subtlety I have yet to understand.  With IPv4, all the
routers in a domain could share the prefix with the individual /32 being
advertised.

Tom Petch

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Mon, 21 Jul 2008 08:06:07 -0700 (PDT)

Yesterday you said  "Also, the virtual Loopback interface is in the same link-local domain as the WAN interface."

Today you say "The Loopback interface doesn't face the downstream or the upstream."

Can explain clearly your architecture?

Francois-Xavier

--- On Mon, 7/21/08, Hemant Singh (shemant) <[email-masked]> wrote:

> To: "Ole Troan" <[email-masked]>
> Cc: "Iljitsch van Beijnum" <[email-masked]>, "IPv6 Operations" <[email-masked]>
> Date: Monday, July 21, 2008, 7:31 AM
> From: [email-masked]
> [mailto:[email-masked]] On Behalf
> Of Ole Troan

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 21 Jul 2008 11:18:42 -0400

The traffic direction of the Loopback interface in the generic router
sense is that the Loopback interface does not face any traffic
direction.  However, the Loopback interface for the CPE Router can
initiate IPv6 address acquisition via the WAN interface to the SP.  

The architecture, I am referring to is Integrated Routing and Bridging
(IRB) - google it.  Such routing can send the RA to other virtual
interfaces of a router.

Hemant

-----Original Message-----
From: Francois-Xavier Le Bail [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 11:06 AM
To: Hemant Singh (shemant)
Cc: Iljitsch van Beijnum; Ole Troan; IPv6 Operations
Subject: RE: Comments on draft-wbeebee-ipv6-cpe-router-01.txt

Yesterday you said  "Also, the virtual Loopback interface is in the same
link-local domain as the WAN interface."

Today you say "The Loopback interface doesn't face the downstream or the
upstream."

Francois-Xavier

--- On Mon, 7/21/08, Hemant Singh (shemant) <[email-masked]> wrote:

> We are not even concerned about the draft being a WG work item.  We 
> have not even completed requirements for the device.
> 
> Also, if you say IA_PD is forbidden by stateless DHCPv6, please point 
> to a MUST NOT text in any RFC.
> 
> > e.g:
> The Loopback interface doesn't face the downstream or the upstream.  
> You and I both know RFC3633 has no explicit text that prohibits 
> stateless
> DHCPv6 asking for IA_PD as I showed how (using the ORO once an 
> interface has acquired a global IPv6 address).
> 
> address on the WAN interface, I suggest you go do a test and get back 
> to us.
> 
> DSL folks have asked to support the WAN interface acquiring a 
> link-local address.  So it is the Loopback interface that acquires a 
> global IPv6 address to source packets to the WAN.  If the Loopback 
> interface is not spawned, then since the LAN interface has global IPv6

> address, one could say, use the LAN interface global address to source

> packets to the WAN.
> But the CPE Router will not even function if the WAN interface has 
> only link-local and the LAN interface has a global IPv6 address
> - see section
> 4 of
> 
> [mailto:[email-masked]] On Behalf Of Ole Troan

---

From: Gert Doering <[email-masked]>
Date: Mon, 21 Jul 2008 17:19:48 +0200

Hi,

> address on the WAN interface, I suggest you go do a test and get back to

Whether or not a specific *implementation* fails with this has nothing
to do whatsoever with "obvious problems".

There is no fundamental problem with uRPF over "unnumbered" interfaces
(be it link-local or explicitely configured as "ipv6 unnumbered <other>").

The example that you have given ("default route is special") is fairly
irrelevant - because it's still special, even if you have a global IPv6
address on the WAN interface.  So you if you do uRPF without a default
route, you will still not be able to receive packets "from the world" - 
you'll be able to receive packets from connected neighbours, and 
nothing else.  Which isn't overly useful.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  110584

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: Mikael Abrahamsson <[email-masked]>
Date: Mon, 21 Jul 2008 17:53:07 +0200 (CEST)

> (IRB) - google it.  Such routing can send the RA to other virtual

For me, a loopback interface is a virtual interface, as per your first 
part. "interface loopback 0" in cisco routers.

If the IP address is in IRB, then it's no longer a loopback interface, 
it's a bridge- or vlan-interface.

---

From: "Ole Troan" <[email-masked]>
Date: Mon, 21 Jul 2008 23:25:24 +0200

> not even completed requirements for the device.

perhaps you would have more success if you wrote down the requirements
instead of arguing for solutions.

> a MUST NOT text in any RFC.

am I the only one thinking this discussion is becoming a little surreal?
_stateless_ DHCP is used in cases where  the DHCP server does not need
to keep and maintain dynamic state for the client. read RFC3736. PD
just as address assignment requires state.

> has acquired a global IPv6 address).

I don't understand what you are trying to say here. you are alluding
to some model where the "loopback" (lets call this a virtual
interface) interface is bridged with the WAN interface. I have no idea
where you are going with that.
when I'm talking about a loopback interface or a virtual interface on
a router it is a L3 interface connected to a separate albeit virtual
link.
you cannot run PD on this interface for obvious reasons. it isn't
connected to a DHCP server.

> address on the WAN interface, I suggest you go do a test and get back to

I don't see the obvious problem, nor do I see any other problems.
perhaps you can enlighten me?

> say, use the LAN interface global address to source packets to the WAN.

how do you intend that a  (routed) loopback interface should acquire an address?
(as a matter of terminology, link-local addresses aren't acquired.
they are generated).

> http://www.ietf.org/internet-drafts/draft-miyakawa-1plus64s-00.txt

untrue, for the host function, routers in general implement the weak
host model. even the implementation alluded to in the draft can be
configured to do that. isn't the purpose of your draft to specify
_how_ a CPE router should be provisioned? or do you want to find the
lowest common denominator among existing IPv6 implementations...

/ot

---

From: Gert Doering <[email-masked]>
Date: Tue, 22 Jul 2008 09:30:15 +0200

Hi,

> Further, even I agree with you that it's not wise for a CPE Router to

Just for the record: we very much value CPEs that respond to pings.

(Configurable rate-limits and/or non-responsiveness is fine, but 
hard-wiring anything that hinders network diagnosis is very bad)

Gert Doering
        -- NetMaster

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 22 Jul 2008 11:45:04 -0400

-----Original Message-----
Sent: Monday, July 21, 2008 5:25 PM

>> perhaps you would have more success if you wrote down the
requirements instead of arguing for solutions.

I think so too.  We thought we could provide solutions to some early
requirements from DSL folks, but as you can see, those solutions need
some ironing out.  We have to get consensus between AT&T, NTT, Mikael
Abrahamsson, and David Miles who works with DSL IPv6 Forum for
requirements.  In that process we also have to filter some requirements
because a requirement might not be possible.  We heard some consensus
between AT&T and NTT when AT&T agreed that they also support a MUST for
global IPv6 address on the WAN interface.  There are other requirements
to be ironed out.  I had told the mailer, unless I meet NTT folks at
IETF 72, I am not clear on their requirements and our draft is subject
to change.  We understand David Miles' requirements fine.  We'll see
what we can do to add a requirements section to the document and
eventually that section also the lists what other section to go to for
what requirement so that any given solution is identifiable for a given
requirement.  If you see the first email from Mikael on our draft,
that's his requirement.  Then see the first email from Shin - that's
NTT's requirement.  Then see the first email from David Miles to see his
requirement.  AT&T's requirements are best seen from any of Barbara's
recent emails marching backwards.

Hemant

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Jul 2008 13:43:53 -0400

> This is such nonsense. I wish you would stop spewing it.

FWIW, I agree with David.

And I wish others would get their heads out of the sand. The reality
is that NAT does have both benefits and drawbacks. Some may think the
drawbacks dwarf all benefits, but anyone who has followed this
discussion for more than 30 seconds has to see that reasonable people
disagree on how to weigh the cost vs. benefits. Can't we just accept
that and move on?

Thomas

---

From: [email-masked]
Date: Wed, 23 Jul 2008 02:30:42 -0600

> disagree on how to weigh the cost vs. benefits. Can't we just accept
Thomas, 

The WG went down that road and more than a year ago agreed that the problems 
out weighed the benefits and thus published RFC4864 after more than 2 years 
of discussion. 

I do not think that this is the right draft to reopen that discussion. 

Eric

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 23 Jul 2008 11:33:47 -0400

BTW, Ole, the high level requirements for DSL are already in the draft,
like totally high level features such as PPP and then new Softwires.
It's more detailed requirements such as WAN with link-local only vs.
only allowing WAN with GUA that are pending.  Also as I said in the past
there is one stock change in the -02 draft replacing stateless DHCPv6
with stateful DHCPv6 for IA_PD acquisition and then draft it fixed -
these are 3-4 places. 

IRB is something we have used time and time on routers and as I said to
this mailer, we have a working CPE Router using IRB in a cable modem at
Cisco. Any interface on our cable modem router can receive the RA sent
to the modem WAN interface if the interface has joined the bridged
group.  Anyhow, we are open to replacing IRB for a different solution.
For example, let users just configure the Loopback interface manually or
automatically (where the interface gets IPv6 address from IA_PD) if NTT
would like that for the CPE Router. 

Some folks have asked for pictures.  We plan to include pictures showing
external and internals of the CPE Router in our IETF 72 presentation. 

Hemant 

-----Original Message-----
Sent: Tuesday, July 22, 2008 11:45 AM
To: Ole Troan

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

Hemant

---

From: David Miles <[email-masked]>
Date: Thu, 24 Jul 2008 17:44:23 +1000

> read ample evidence given for this one.

When Shin was pointing out the considerations for a loopback, Francois- 
Xavier noted:
"When the CPE router has only a link-local address on the WAN port, if  
the CPE has a LAN bridge, I hope there is an option to have the global- 
scope address set on the LAN bridge (from IA_PD via DHCPv6) as an  
alternative to loopback solution."
Between Shin, Francois-Xavier, Ole and others it seemed there was an  
appreciation that loopbacks were not required to support the  
unnumbered model - best summarised in Shin's email on 3 July. (I'm not  
suggesting everyone thought the unnumbered model was preferred, but  
that there was no technical obstacle).

RFC 3484 says:
It is RECOMMENDED that the candidate source addresses be the set of  
unicast addresses assigned to the interface that will be used to send  
to the destination. (The "outgoing" interface.) On routers, the  
candidate set MAY include unicast addresses assigned to any interface  
that forwards packets, subject to the restrictions described below.
This seems to hit the nail on the head - we are describing a router  
that MAY use a unicast address assigned to any interface (LAN) subject  
to the restrictions in RFC 3484 (which do not pose any problem in my  
interpretation). I initially raised the use of a loopback as an option  
because I was concerned about LAN interface state (and said so in the  
original thread). If the LAN interface is a bridge (always up) I see  
no mandatory need for a loopback. I would urge continued discussion in- 
list if there are technical arguments against a un-numbered model  
without loopback. The two points raised in favour of such an option  
are that : it avoids an additional /64 for the loopback, and; caters  
to CPE that may not support a loopback interface (may need to be  
qualified).

IE (a reference for a routing CPE with internal MAC bridge):

       +------------------------+
       | Routing CPE w/ bridge  |
       | +------+     +------+  |
Port1-|-|      |     |      |  |
       | |Bridge|-----|Router|--|----WAN
Port2-|-|      |  LAN|      |  |
       | +------+     +------+  |
       +------------------------+

LAN is connected to a bridge device so it is always up.

Addresses:
WAN: 	fe80::<iid>%wan prefixlen 64
LAN:  	2001:db8:0:1::<iid> prefixlen 64 (example)
		fe80::<iid>%lan prefixlen 64

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 25 Jul 2008 11:57:19 -0400

David,

Barring Shin's concern that even if a LAN interface on the CPE Router is
up with a GUA but the WAN interface of the CPE Router does not have a
GUA acquired, using a GUA of a LAN interface is fine as source for WAN
packet to the SP.  This is the Cisco IOS unnumbered interface model.
Then the Loopback interface is not required.  Sorry, some folks like
Iljitsch thought our draft was alluding to the Cisco IOS unnumbered
interface model seeing the "Unnumbered Model" section of our draft.  Our
draft was NOT referring to the IOS unnumbered model, we just used the
term in our draft to signify that the WAN doesn't have a GUA assigned to
it.  The Unnumbered Model is our -02 draft was merely providing a
solution with Loopback interface that folks had asked for at the time.

Sorry, I haven't been able to understand all of Shin's concerns
completely and that is why I am meeting him at IETF to get to the bottom
of things.  As a separate observation, Ole has shot down the Shin
1plusus64s draft and the draft's concern in section 4.  I don't
understand all of Shin's concerns to shoot down his draft or not. 

Yes, the internals of the CPE Router does include a bridge that is
always up if the router is powered up.  Further, notice from RFC4241
that the Loopback interface used in that RFC's DSL Deployment is
provisioned for an anycast address for ping checks.  We will add such
information to our draft that the optional Loopback interface can be
spawned for the anycast address ping.  

Hemant & Wes

-----Original Message-----
From: David Miles [mailto:[email-masked]] 
Sent: Thursday, July 24, 2008 3:44 AM
To: Hemant Singh (shemant)
Cc: v6ops WG
Subject: Re: New (-02) version of IPv6 CPE Router draft is available for
review

When Shin was pointing out the considerations for a loopback, Francois-
Xavier noted:
"When the CPE router has only a link-local address on the WAN port, if
the CPE has a LAN bridge, I hope there is an option to have the global-
scope address set on the LAN bridge (from IA_PD via DHCPv6) as an
alternative to loopback solution."
Between Shin, Francois-Xavier, Ole and others it seemed there was an
appreciation that loopbacks were not required to support the unnumbered
model - best summarised in Shin's email on 3 July. (I'm not suggesting
everyone thought the unnumbered model was preferred, but that there was
no technical obstacle).

RFC 3484 says:
It is RECOMMENDED that the candidate source addresses be the set of
unicast addresses assigned to the interface that will be used to send to
the destination. (The "outgoing" interface.) On routers, the candidate
set MAY include unicast addresses assigned to any interface that
forwards packets, subject to the restrictions described below.
This seems to hit the nail on the head - we are describing a router that
MAY use a unicast address assigned to any interface (LAN) subject to the
restrictions in RFC 3484 (which do not pose any problem in my
interpretation). I initially raised the use of a loopback as an option
because I was concerned about LAN interface state (and said so in the
original thread). If the LAN interface is a bridge (always up) I see no
mandatory need for a loopback. I would urge continued discussion in-
list if there are technical arguments against a un-numbered model
without loopback. The two points raised in favour of such an option are
that : it avoids an additional /64 for the loopback, and; caters to CPE
that may not support a loopback interface (may need to be qualified).

Addresses:

---

From: Francois-Xavier Le Bail <[email-masked]>
Date: Sat, 26 Jul 2008 01:32:29 -0700 (PDT)

--- On Fri, 7/25/08, Hemant Singh (shemant) <[email-masked]> wrote:
> Yes, the internals of the CPE Router does include a bridge
> that is always up if the router is powered up.

So, the CPE Router need a MLD snooping function [RFC4541] on the LAN bridge.

Francois-Xavier