Subject: draft-wbeebee-ipv6-cpe-router-04 comments

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 10:58:17 -0700

everyone--

I see this topic came up once before, but I have a different comment.

-----
Section 5 "Basic IPv6 Provisioning" says:
> The CPE Router MUST support at least one of two WAN interface  
> models, one of which will be active on the CPE Router at any given  
> time.
p1. If the CPE router only supports one of the two, then only one will  
be active at any given time.

p2. If I were running an ISP, I'd be very suspicious of this  
requirement on CPE router vendors that they MUST support "at least one  
of two" and not both WAN interface models.  Fortunately, I'm on the  
other side of that fence, so I'm very pleased to see that I can refuse  
to support the Unnumbered Model and still comply with Best Current  
Practice.

p3. I'm deeply confused about how the default route is communicated to  
the CPE router over its WAN link from the service provider in the  
Unnumbered Model.

-----
Section 5.4 "Process RAs"

Do these include RFC 4191 More Specific Route advertisements?  Yay!   
That will make the rogue RA problem a whole lot more fun.

-----

I'm still going through the draft.  Sorry for my slow progress.  Sigh.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 14:25:03 -0400

In line below between <hs-wb> and </hs-wb>.

<hs-wb>
This is exactly what the CableLabs specified eRouter does.
</hs-wb>

<hs-wb>
Numbered or Unnumbered models aside, the CPE Rtr receives an RA from the
neighboring first hop SP router. CPE Rtr receives the RA and knows this
is the IPv6 default router.
</hs-wb>

-----

<hs-wb>
This section clearly discusses only the direction where an RA comes to
the CPE Rtr from the SP router to the home.  For a cable and DSL network
the SP to the cable modem or DSL modem link is cable RF transport or DSL
telco network.  Such networks are deemed very secure.  A Rogue RA is not
expected in this direction.   Outside of this section of our document,
we can totally agree that a rouge RA may be sent from say, a Windows or
MAC personal computer attached to the CPE Rtr in a direction upstream
from the CPE Rtr to the SP network.  A CPE Rtr has to block any RA from
the home to the SP network.  
</hs-wb>
-----

<hs-wb>
No worries.  Comments are welcome any time.
</hs-wb>

Hemant & Wes

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 12:24:24 -0700

> is the IPv6 default router.

I don't see in the Unnumbered Model where the CPE is required to send  
any RS, nor do I think it's safe to assume that CPE routers will ever  
receive any unsolicited multicast RA announcements.

> expected in this direction.

Be careful here.  RFC4191 MoreSpecificRoute messages, properly formed,  
are neither rogue nor accidental.

So.  Are CPE routers required to process RFC4191 MoreSpecificRoute  
options, or are they required to ignore them?  Or does this draft even  
want to take a position?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 17:08:14 -0400

>receive any unsolicited multicast RA announcements.

When a network interface on any router inits itself and performs any
"address acquisition", the network interface of the router is acting as
a host.  According to RFC 4861, section 4.1, the text says that hosts
send RS to solicit an RA quickly.  Even in the Unnumbered model, the CPE
Router will use a LAN interface or Loopback interface IPV6 address to
source packets - this is equivalent to the WAN interface "acquiring" an
address.  However, it is loose.  We can certainly mandate in the
Unnumbered section that the WAN interface MUST send an RS. 

>want to take a position?

This draft takes the position taken by RFC 4861 which in section 4.2
says
[Future versions of this protocol may define new option types.
 Receivers MUST silently ignore any options they do not recognize
 and continue processing the message.]

Cable CMTS and DSLAM nodes at the SP edge have no need to be multi-homed
which is one reason to consider RFC 4191.  Also if you look at the "IPv6
Node Requirements RFC 4294-bis", this document does NOT mention RFC 4191
and hence so we won't either.  Is there a compelling reason for the CPE
Rtr to support RFC 4191?  If there is, you have to take it up first with
the "IPv6 Node Requirements RFC 4294-bis" folks.

Hemant

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 14:23:07 -0700

On Mar 23, 2009, at 14:08, Hemant Singh (shemant) wrote:
> We can certainly mandate in the Unnumbered section that the WAN  
> interface MUST send an RS.

I think that might help clarify the issue.

> says [Future versions of this protocol may define new option types.

Does RFC 4191 not predate RFC 4861?  Yes, I realize that RFC 4191 was  
not categorized as an update of RFC 2461, the predecessor of RFC 4861,  
but it's really not fair to treat a standards-track RFC published over  
three years ago as a "future" specification.

If the draft doesn't want to take a position on whether CPE routers  
MUST, SHOULD NOT, MAY or MAY NOT process RFC 4191 More Specific Route  
options, then I think it would help to be explicit about it.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Mar 2009 17:41:12 -0400

>I think that might help clarify the issue.

Thank you for bringing up this point.  We will clarify the RS in the
Unnumbered model in the next revision of the draft.

>options, then I think it would help to be explicit about it.

We are working off of the "IPv6 Node Requirements RFC 4294-bis" and
won't go against this document.  If a gotcha is found, we will have RFC
4294-bis changed and then apply the change to the CPE Rtr.  Since RFC
4294-bis does not mention RFC 4191, our draft's position is crystal
clear in this regard.  Our draft will follow RFC 4861 because that is
what RFC 4294-bis goes by.  Again, unless something is critically needed
from RFC 4191 to be mandated for the CPE Rtr, we may close this
discussion. 

Thanks,

Hemant

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 14:47:10 -0700

On Mar 23, 2009, at 10:58 AM, james woodyatt wrote:

> requirement on CPE router vendors that they MUST support "at least  
> one of two" and not both WAN interface models.  Fortunately, I'm on  
> the other side of that fence, so I'm very pleased to see that I can  
> refuse to support the Unnumbered Model and still comply with Best  
> Current Practice.

That wasn't how I interpreted it. It said that you need to support  
both, as some ISPs will go one way and some the other.

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 15:12:31 -0700

On Mar 23, 2009, at 14:41, Hemant Singh (shemant) wrote:
>
> ...unless something is critically needed from RFC 4191 to be  
> mandated for the CPE Rtr, we may close this
> discussion.

I want the draft amended to recognize explicitly that CPE routers MAY  
transmit and receive RFC 4191 More Explicit Route messages on their  
WAN link.

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 15:28:33 -0700

> both, as some ISPs will go one way and some the other.

Then I think this recommendation should be worded differently.  It  
could better describe this by using language that makes sense from the  
perspective of CPE router developers, e.g.:

   Service providers require CPE routers to support at least one of two
   WAN interface models, of which only one MUST be active on the CPE  
router
   at any given time.

I think that would more clearly describe Fred's interpretation of the  
language I'm seeing in the existing draft.  As the draft stands, I  
don't see any recommendation that CPE routers support both of the two  
WAN interface models, only a recommendation to support "at least one"  
of them.

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Mar 2009 15:57:19 -0700

On Mon, Mar 23, 2009 at 3:12 PM, james woodyatt <[email-masked]> wrote:
>> ...unless something is critically needed from RFC 4191 to be mandated for
>> the CPE Rtr, we may close this
>> discussion.
>
> transmit and receive RFC 4191 More Explicit Route messages on their WAN
> link.

and turning ND into a routing protocol?

Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 16:02:15 -0700

On Mar 23, 2009, at 15:57, Ole Troan wrote:
>
> ...and turning ND into a routing protocol?

 From Section 1 of RFC 4191:
>> We use Router Advertisement messages, instead of some other  
>> protocol like RIP [RFC2080], because Router Advertisements are an  
>> existing standard, stable protocol for router-to-host  
>> communication. Piggybacking this information on existing message  
>> traffic from routers to hosts reduces network overhead. Neighbor  
>> Discovery shares with Multicast Listener Discovery the property  
>> that they both define host-to-router interactions, while shielding  
>> the host from having to participate in more general router-to- 
>> router interactions. In addition, RIP is unsuitable because it does  
>> not carry route lifetimes so it requires frequent message traffic  
>> with greater processing overheads.

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Mar 2009 16:39:00 -0700

On Mon, Mar 23, 2009 at 4:02 PM, james woodyatt <[email-masked]> wrote:
>>> We use Router Advertisement messages, instead of some other protocol like
>>> RIP [RFC2080], because Router Advertisements are an existing standard,
>>> stable protocol for router-to-host communication. Piggybacking this
>>> information on existing message traffic from routers to hosts reduces
>>> network overhead. Neighbor Discovery shares with Multicast Listener
>>> Discovery the property that they both define host-to-router interactions,
>>> while shielding the host from having to participate in more general
>>> router-to-router interactions. In addition, RIP is unsuitable because it
>>> does not carry route lifetimes so it requires frequent message traffic with
>>> greater processing overheads.

indeed. MSR is a router-to-host mechanism. the CPE acts for some
purposes as a host on the upstream interface. do you expect the MSR
routes to be limited to be used only for the host part of the CPE (i.e
communication originating from the CPE) or to make it into the CPE's
forwarding table?

Ole

---

From: james woodyatt <[email-masked]>
Date: Mon, 23 Mar 2009 17:41:46 -0700

On Mar 23, 2009, at 16:39, Ole Troan wrote:
>> protocol like

Yes, naturally.  Why not?

If I were planning to implement a CPE router that processed received  
RA with RFC 4191 MSR options, I'm pretty sure I would do it so that  
the routes used by the node implementation were the same routes used  
by the forwarding implementation.  It would be a lot of extra hassle  
to maintain two route tables, and the payoff would seem quite unclear  
to me.

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Mar 2009 18:28:15 -0700

James,

>> communication originating from the CPE) or to make it into the CPE's

because we have protocols doing that already? (RIP, OSPF, ISIS, BGP...)

> If I were planning to implement a CPE router that processed received RA with
> RFC 4191 MSR options, I'm pretty sure I would do it so that the routes used
> by the node implementation were the same routes used by the forwarding
> implementation.  It would be a lot of extra hassle to maintain two route
> tables, and the payoff would seem quite unclear to me.

iff you wanted to make ND into a routing protocol using MSRs, I
believe you would have to change RFC4191. and possibly the main ND
spec, as routers doesn't listen to ND.

if I understand this draft correctly it behaves both as a host (doing
address assignment) and as a router (forwarding packets) on the
upstream interface. that behaviour isn't described in RFC4861. I don't
see any harm in e.g doing SLAAC as that's purely a host function.
processing MSR routes on the other hand configures the router.

Ole

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 24 Mar 2009 10:28:33 -0400

CableLabs has decided in the eRouter specification (one particular
instantiation of the CPE Router) that cable providers will never use the
unnumbered model.  Therefore, for the eRouter (which will only
ever be used in a cable network), the unnumbered model is not required.

However, DSL/3GPP networks will likely use the unnumbered model.

If a CPE Router can be used in both networks (like a standalone CPE
Router), then you'll need to 
support both - because you can't be certain who will be using your
router.

Therefore, you'll need to support both unless you have linktype-specific
knowledge that allows you to rule one out.

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fred Baker (fred)
Sent: Monday, March 23, 2009 5:47 PM
To: james woodyatt
Cc: IPv6 Operations
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

> to support the Unnumbered Model and still comply with Best Current 

That wasn't how I interpreted it. It said that you need to support both,
as some ISPs will go one way and some the other.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Mar 2009 07:57:11 -0700

And there needs to be a way in which the CPE router can determine what  
mode it is supposed to operate in ... no matter whether it is  
connected directly to a WAN link (cable or DSL or IPoSN) or to a link  
inside the subscriber network.

- Ralph

On Mar 24, 2009, at 7:28 AM 3/24/09, Wes Beebee (wbeebee) wrote:

>> one
> both,

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Mar 2009 21:34:14 -0400

Ralph,

Note the our draft covers both an embedded CPE Rtr and a standalone CPE
Rtr.  If the CPE Rtr is embedded in a cable or DSL modem, or 3GPP legacy
data device, then the L2 of the modem or 3GPP device can easily signal
the upper layers of the Rtr to be configured for cable, DSL, or 3GPP WAN
interface setup. 

For a standalone CPE Rtr, if one reads the draft, one will see that if
the CPE Rtr WAN interface sees an RA with M and O bits set when no PPP
link has been established prior to seeing this RA, it's a cable
deployment.  If an RA is seen after PPP negotiation, it's a DSL
deployment.  These are some ideas we have in mind thus far.  We can
certainly look into a flow chart for such provisioning in the standalone
rtr case.  Alternatively, for the standalone case, we may leave it to
the vendors to differentiate between their products as to how automatic
is their standalone CPE Rtr provisioning.  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ralph Droms (rdroms)
Sent: Tuesday, March 24, 2009 10:57 AM
To: IPv6 Operations
Cc: Fred Baker (fred); james woodyatt
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

- Ralph

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 24 Mar 2009 18:55:24 -1000 (HST)

On Tue, 24 Mar 2009, Hemant Singh (shemant) wrote:

> deployment.

It's hard to figure out where in the draft the deployment type is actually 
specified.  Regardless, the above may not be a good assumption.  Our DSL 
deployment here for example currently uses SLAAC and RAs.  PD is currently 
done manually.  Eventually we want to use DHCPv6 for PD to the CPE router. 
We don't use PPP at all for either IPv4 or IPv6 on DSL.

> If an RA is seen after PPP negotiation, it's a DSL deployment.

So I wonder, what does the deployment 'type' have anything to do with the 
CPE Router behavior?

Antonio Querubin
whois:  AQ7-ARIN

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 25 Mar 2009 15:49:37 +0100

Hello Hemant,

> deployment.  If an RA is seen after PPP negotiation, it's a DSL

I'm not sure the criteria you mentioned is enough to identify a DSL CPE: in DSL environment you can have either PPP or IP Sessions. In case of IP Sessions if SLAAC is used to number the WAN link you will see RA with M and O bits set.

Best Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, March 25, 2009 2:34 AM
To: Ralph Droms (rdroms); IPv6 Operations
Cc: Fred Baker (fred); james woodyatt
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

Ralph,

Hemant

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

- Ralph

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Mar 2009 11:08:12 -0400

>We don't use PPP at all for either IPv4 or IPv6 on DSL.

The intent of our document is not to specify deployment type - we define
a set of Conceptual Configuration Variables that a vendor may use to
implement the CPE Router.  For old networks that have not moved to
DHCPv6 PD, I am not surprised manual configuration has been used.  Even
with DHCPv6 PD, we will have to work out details to see how much
automatic configuration is possible.  Notice for IPv4 standalone home
routers, most routers still need a manual configuration to choose if the
home has a DSL or cable broadband access.  Also, in your DSL deployment,
do you have an embedded router in a DSL modem or is the router a
standalone router?  An embedded router has lot more automatic
configuration because the L2 of the device can communicate internally to
the embedded CPE Router.

Hemant

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 25 Mar 2009 16:13:29 +0100

>In case of IP Sessions if SLAAC is used to number the WAN link you will see RA
> with M and O bits set

I missed a NOT; I meant if SLAAC is NOT used, sorry.

Roberta

-----Original Message-----
From: Maglione Roberta
Sent: Wednesday, March 25, 2009 3:50 PM
To: 'Hemant Singh (shemant)'; Ralph Droms (rdroms); IPv6 Operations
Cc: Fred Baker (fred); james woodyatt; Wojciech Dec
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

Hello Hemant,

Best Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Wednesday, March 25, 2009 2:34 AM
To: Ralph Droms (rdroms); IPv6 Operations
Cc: Fred Baker (fred); james woodyatt
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

Ralph,

Hemant

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

- Ralph

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Mar 2009 11:17:02 -0400

>I'm not sure the criteria you mentioned is enough to identify a DSL
CPE: in DSL environment you can have either PPP or IP Sessions. In case
of IP Sessions if SLAAC is used to number the WAN link you >will see RA
with M and O bits set.

I was referring specifically to a DSL deployment if the network uses
PPP.  Of course, for other flavors of deployment, one has to work out
details to see how much automation is possible with the CPE Router
configuration. Also, note, if a DSL deployment uses embedded router (DSL
modem combined with a CPE Router), then the device vendor has complete
flexibility for lot of automatic configuration because the L2 of the DSL
modem can communicate with the embedded CPE Router; likewise for an
embedded router in a cable modem.  See my earlier email where I said we
are focused more on Conceptual Configuration variables that may be left
to a vendor to use to automate whatever they would like to for
configuration. 

Hemant

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 Mar 2009 10:28:25 -0700

> spec, as routers doesn't listen to ND.

I only see a requirement in RFC 4294 (and draft-ietf-6man-node-req- 
bis-02) to send RS and process received RA at hosts.  There is no  
language that says routers MUST NOT send RS and process received RA,  
as draft-wbeebee-ipv6-cpe-router describes.

You have a point about RFC 4191 perhaps needing to be amended.  It  
describes MSR as a router-to-host protocol and not a router-to-node  
protocol.  This strikes me as an oversight that should be corrected.   
I see no technical reason that only hosts and not all nodes should be  
permitted to process MSR messages.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 25 Mar 2009 14:05:44 -0400

Where do we say that CPE Routers MUST NOT send RS's?

That was certainly not the intent of the draft...

- Wes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of james woodyatt
Sent: Wednesday, March 25, 2009 1:28 PM
To: IPv6 Operations
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

I only see a requirement in RFC 4294 (and draft-ietf-6man-node-req-
bis-02) to send RS and process received RA at hosts.  There is no
language that says routers MUST NOT send RS and process received RA, as
draft-wbeebee-ipv6-cpe-router describes.

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 Mar 2009 11:08:58 -0700

> That was certainly not the intent of the draft...

I see how my comment used ambiguous language.  I meant to say that A)  
I do not see how RFC 4294 and draft-ietf-6man-node-req-bis-02 prohibit  
CPE routers from sending RSs and processing RAs, and B) I *do* see  
where draft-wbeebee-ipv6-cpe-router-04 calls for CPE routers to do  
exactly that.

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 25 Mar 2009 08:10:41 -1000 (HST)

On Wed, 25 Mar 2009, Hemant Singh (shemant) wrote:

> home has a DSL or cable broadband access.

Here, both types of access is usually through a modem, not a router. The 
modem provides the customer with ethernet.  If the customer chooses to 
install a standalone router chained off of the modem, there's really no 
additional choice to be made.  The only choice is whether to go with a 
cable or DSL access provider.  Once that choice is made, the modem type is 
already determined.

> Also, in your DSL deployment, do you have an embedded router in a DSL 
> modem or is the router a standalone router?  An embedded router has lot 
> more automatic configuration because the L2 of the device can 
> communicate internally to the embedded CPE Router.

That depends on the customer.  In the embedded case, conceptually it's 
simplest to think of the device as having a virtual ethernet connection 
between built-in modem and built-in router (when the customer chooses to 
use an embedded router device they normally lose the option to hang 
additional devices off the WAN link).  I'm not aware of any consumer 
embedded-router/modem being used here where the router functionality 
behaves significantly differently than that of a standalone-router. The 
communication between the L2 device and the router really boils down to 
whether the WAN connection is up or down and that's really independent of 
whether an embedded router or standalone router is being used.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Ole Troan <[email-masked]>
Date: Wed, 25 Mar 2009 11:34:49 -0700

>> iff you wanted to make ND into a routing protocol using MSRs, I believe
>> you would have to change RFC4191. and possibly the main ND spec, as routers
>> doesn't listen to ND.
>
> I only see a requirement in RFC 4294 (and draft-ietf-6man-node-req-bis-02)
> to send RS and process received RA at hosts.  There is no language that says
> routers MUST NOT send RS and process received RA, as

routers don't send RSs hosts do. but I agree to the extent that the
host/router property is per-interface. and the distinction becoming
more blurred by the day in any case.

> You have a point about RFC 4191 perhaps needing to be amended.  It describes
> MSR as a router-to-host protocol and not a router-to-node protocol.  This
> strikes me as an oversight that should be corrected.  I see no technical
> reason that only hosts and not all nodes should be permitted to process MSR
> messages.

this was something which was touched upon by Ralph's presentation in
the rtgarea meeting. I think this needs more consideration and include
a wider audience; should we make DHCP and ND into routing protocols?

btw, from RFC4861, section 6.2.7:
"...Any other action on reception of Router Advertisement messages by a
   router is beyond the scope of this document."

Ole

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Mar 2009 15:46:27 -0400

James,

I already replied to your RS question on March 23.  Ole has also kindly
jumped in later too and gave you an explanation in this regard. Here is
what I said on 03/23.  From this text it should be crystal clear why a
router's network interface is legal to send an RS and also by sending
the RS, the CPE Rtr's network interface is not non-compliant to any IPv6
node req document.

"When a network interface on any router inits itself and performs any
"address acquisition", the network interface of the router is acting as
a host.  According to RFC 4861, section 4.1, the text says that hosts
send RS to solicit an RA quickly."

The only recent item to debate from you is now RFC 4191.  Again, on this
front Ole articulated it very nicely and I agree with him.  If one has
routing, why do we want RFC 4191 in the CPE Rtr document? I have also
asked in the past to please give us one compelling reason to make RFC
4191 get into the CPE Rtr document.  What particular option from RFC
4191 do you want to use by the CPE Rtr?

Hemant

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 Mar 2009 16:06:19 -0700

On Mar 25, 2009, at 12:46, Hemant Singh (shemant) wrote:
> I have also asked in the past to please give us one compelling  
> reason to make RFC 4191 get into the CPE Rtr document.  What  
> particular option from RFC 4191 do you want to use by the CPE Rtr?

I must have missed the request for "one compelling reason" for CPE  
routers to send and receive RFC 4191 more specific route information  
messages on their WAN links.  My apologies.

Please let me clarify my remarks and narrow my request somewhat, now  
that I've had a chance to review more of the CPE Router draft.  I am  
only interested in such RFC 4191 messages when a valid PIO has been  
received on the WAN link with L=1.  No other cases are interesting.

The reason I want this should be obvious: so that a CPE router may  
advertise its local prefix on the WAN link to other nodes so as to  
eliminate the need for traffic that originates from them to have to  
hairpin through their default router to be delivered.

---

From: james woodyatt <[email-masked]>
Date: Wed, 25 Mar 2009 16:16:39 -0700

> received on the WAN link with L=1.  No other cases are interesting.

I take it back.  It's interesting in the other cases as well.  Two CPE  
routers attached to the same link will exchange their prefixes with  
MSR advertisements regardless of whether the RAs from the service  
provider have PIO options in them.  As they should.

---

From: Mark Smith <[email-masked]>
Date: Thu, 26 Mar 2009 19:24:55 +1030

Hi,

On Wed, 25 Mar 2009 16:06:19 -0700

> hairpin through their default router to be delivered.

I agree with James. An implementation model of ADSL with Ethernet
backhaul (TR-101) is to have all CPE sitting in the same "bridged
Ethernet over ADSL" VLAN, ethernet switched in the local telephone
exchange / C.O., with the default router off site, also in the same
VLAN. Having the CPE announce their prefixes to each other would keep
inter-CPE traffic off of the expensive backhaul links. If P2P
applications/traffic become much more locality aware, this would be of
great benefit.

Regards,
Mark.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Mar 2009 10:51:57 +0100 (CET)

> applications/traffic become much more locality aware, this would be of 

This sound like a huge security problem, how are those implications 
handled? Wouldn't the L2 device in the CO need to be able to inspect all 
these messages and drop ones which are not assigned to that specific 
customer by the ISP?

In the scenarios I have seen before mechanisms such as forced forwarding 
and/or mac rewrite/DHCP snooping based ACLs been used in the CO L2 device 
to handle this, what are the IPv6 equivalents in this scenario?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 26 Mar 2009 10:57:04 -0400

>to handle this, what are the IPv6 equivalents in this scenario?

Thank you, Mikael.  I just sent email that I too consider such behavior
to be a security hole and gave the rationale for it.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 26 Mar 2009 10:55:11 -0400

James and Mark,

Did you see the security liaison sent to v6ops from the DSL Broadband
Forums folks?  Fred Baker sent it out to the v6ops mailer this week.
DSL is precisely discussing a fact that modems will have to go thru a
default router rather than communicating directly to each other which is
what you two are proposing.  I think we have to let the Broadband forum
complete their IPv6 standards and then depending upon what they do, we
can revisit this RFC 4191 question.  

At this point I would like you all to see this text below that I and Wes
wrote in an expired draft of
draft-wbeebee-on-link-and-off-link-determination-01.txt.

Hemant

[3.  Router Models

   The Redirect Clarifications section clarifies RFC 4861 [ND] host and
   router behavior for an aggregation router deployment.

   The Aggregation Router Deployment Model section presents a possible
   aggregation router deployment model for IPv6 and discusses its
   properties with respect to ND.  Aggregation routers can service more
   than 100,000 subscribers.  Due to scaling considerations, any NS for
   global address resolution from any host to any other host should not
   reach the aggregation router.

3.1.  Aggregation Router Deployment Model

   A property of routed aggregation networks is that hosts cannot
   directly communicate with each other even if they share the same
   prefix.  Physical connectivity between the aggregation router and the
   modems prevents hosts behind modems to communicate directly with each
   other.  Hosts send their traffic to aggregation router.  This design
   is motivated by scaling and security considerations.  If every host
   could receive all traffic from every other host, then the
   subscriber's privacy would be violated and the amount of bandwidth
   available for each subscriber would be very small.  That is why hosts
   communicate between each other through the aggregation router, which
   is also the IPv6 first-hop router.

   For scaling reasons, any NS to resolve any address other than that of
   the default router should not reach the aggregation router.

                           +-----+
                           |     |
                           |Aggre+----(Rtr CPE)----Host1
            Core----WAN----+gator|
                           | Rtr |
                           |     +----(Br CPE)----(Cust Rtr)----Host2
                           +-----+

                                 Figure 1.

   In the figure above, the customer premises equipment (CPE) is managed
   by the ISP and is deployed behind an aggregation router that is an
   IPv6 first-hop router and also a DHCPv6 relay agent.  IPv6 CPEs are
   either IPv6 routers (Rtr CPE) or IPv6 bridges (Br CPE).  If the
   customer premises uses a bridge CPE, then a router (Cust Rtr) is
   needed.  All hosts reside behind a router CPE or a customer router.

   No NS to resolve any address other than that of the default router

Singh & Beebee            Expires July 4, 2008                  [Page 7]

Internet-Draft          ND On-link Determination            January 2008

   will reach the aggregation router from any device on the customer
   side of the aggregator.  CPEs do not communicate with each other in
   this deployment model since a CPE does not run any applications that
   need to communicate with other CPEs.  Hosts do communicate with each
   other, but every host is off-link to any other host on the
   aggregation router.]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2009 05:43:53 +1300

Hemant,

> can revisit this RFC 4191 question.  

If the broadband forum people don't want a use case with direct CPE-CPE
communication, that's their choice, but we shouldn't artificially
restrict this in the base spec for CPEs, IMHO. We write IPv6 basic
standards; they apply them to their use cases.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Mar 2009 17:53:05 +0100 (CET)

On Thu, 26 Mar 2009, [email-masked] wrote:

> Normally the customers are separated from each other by split horizont mchanisms and MAC adress translation techniques.

Yes, but that defeats the whole purpose of the proposal from Mark Smith if 
I correctly interpret the scenario he proposed.

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 26 Mar 2009 15:38:14 -0400

> I think we have to let the Broadband forum

The capabilities described in RFC 4191 are certainly something the BBF
is looking at, and it would be interesting to hear IETF thoughts on the
cases that it might handle. 

Here are some possible scenarios:
(1) CPE Router has multiple WAN connections. Let's say one is a
"default" connection that goes to the Internet, while the other is a
connection to a walled garden, or a corporate network, or such. The CPE
router gets prefixes delegated from each, and makes those prefixes
available on its LAN. Is it appropriate / useful for the secondary
network to use RFC 4191 to state which prefixes are behind it? In this
case, the CPE router would need to put that information in its routing
table. Should the CPE Router also use RFC 4191 to tell devices on its
LAN that it supports "default" routes plus these secondary prefixes?

(2) CPE Router has a wired WAN connection and a backup wireless WAN
connection. Both support "default" connectivity. RFC 4191 could be used
by the wireless connection to state that it's less preferred. A better
solution would probably be to just configure the CPE router with that
knowledge. The wireless network isn't the right place to house the
knowledge of whether or not it's preferred. I don't think RFC 4191 would
be used well here, but it's something to think about.

(3) The home has multiple connections through multiple routers. Perhaps
one of these routers is like the router in (1) above, while another
router also supplies a "default" connection, and yet a 3rd supplies a
connection to a walled garden service (maybe it does this by tunneling
over one of the other connections -- if so, this should be invisible to
the hosts in the LAN). Each router advertises prefix(es) to the LAN. It
makes sense for the router to also advertise which prefixes it can
route, especially the walled garden prefixes, which may not be
accessible through any other connection.

RIPng (or other protocols like it) doesn't really seem to be the right
answer here. As mentioned in the CPE Router draft, it has scalability
concerns in the access network. And it seems kind of weird in the LAN.
But using RFC 4191 to supply route info in the RA would be pretty easy.
This route info is fairly static.

By the way -- these are all real scenarios. People and service providers
do these things. They just don't always do them well, today. (1) is
particularly common in IPv4, and is handled through static routing table
entries.
Barbara

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 26 Mar 2009 09:36:16 -1000 (HST)

On Thu, 26 Mar 2009, Mikael Abrahamsson wrote:

> This sound like a huge security problem, how are those implications handled? 
> Wouldn't the L2 device in the CO need to be able to inspect all these 
> messages and drop ones which are not assigned to that specific customer by 
> the ISP?

Perhaps you're assuming that multiple customers are sharing the same 
subnet?  In the case where customers do NOT share subnets, I fail to see 
how this adds a security problem that didn't already exist before.  In 
IPv4, if a DSL provider gives a customer a /28 instead of /30 for the WAN 
link, that customer could easily hang multiple CPE routers off of their 
WAN-side ethernet switch now and they could talk to each other.  Some of 
our customers use their WAN subnet as a DMZ and their routers are 
firewalls.  But the communication on the WAN subnet between customer 
devices stays on the local ethernet switch and shouldn't traverse the DSL 
loop.  I don't think we should cripple that capability for IPv6.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Antonio Querubin <[email-masked]>
Date: Thu, 26 Mar 2009 10:14:18 -1000 (HST)

> particularly common in IPv4, and is handled through static routing table

Concur.  Even for the general case of multiple cascaded CPERs, I think we 
do want them to know how to talk directly to each other rather than 
forcing all intra-customer traffic through the next upstream CPER.

Antonio Querubin
whois:  AQ7-ARIN

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 26 Mar 2009 16:31:22 -0400

James,

-----Original Message-----
From: james woodyatt [mailto:[email-masked]] 
Sent: Wednesday, March 25, 2009 7:17 PM
To: IPv6 Operations
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

>provider have PIO options in them.  As they should.

Wow! Next time it is better you send us ascii diagram of the network
topology you are talking about because I was on a totally different page
than you were.  Thanks to my Cisco colleague in Ole who talked with you
at the IETF and then Ole pinged my buddy Wes and explained your
topology, I realized, I am talking one thing while you are talking
another.  We were all thinking that the CPE Rtr would be the first hop
in the home while you were describing a hub directly behind the
broadband modem.  The hub is a totally broken model to deploy your
Airport Extreme with the Apple TV.  The hub sends all your video to the
SP, say Comcast, and your home access will be shutdown fairly soon
because the home hogged so much of their network bandwidth with the
video going between the Apple TV and Airport Extreme. Sorry, I don't
consider this totally broken network as a reason to add MSR RFC 4191 to
the CPE Rtr just yet.

Thanks, Wes, and Ole.

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 26 Mar 2009 17:04:11 -0400

>And it seems kind of weird in the LAN.

For two or more routers that have to communicate between each other in a
LAN, using RIPng between the routers is the most common-place and
sensible thing to do including if two routers sit in a broadband
connected home.  Yes, if one has router to host communication going on,
then some other protocol may make sense.  Thanks for providing your
typical customer deployments.  We will go thru them and see what we can
suggest.

Thanks,

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 26 Mar 2009 22:08:46 +0100 (CET)

On Thu, 26 Mar 2009, Antonio Querubin wrote:

> IPv4, if a DSL provider gives a customer a /28 instead of /30 for the 
> WAN link, that customer could easily hang multiple CPE routers off of 
> their WAN-side ethernet switch now and they could talk to each other. 
> Some of our customers use their WAN subnet as a DMZ and their routers 
> are firewalls.  But the communication on the WAN subnet between customer 
> devices stays on the local ethernet switch and shouldn't traverse the 
> DSL loop.  I don't think we should cripple that capability for IPv6.

Yes I was under the impression that what Mark Smith was referring to was 
multiple residential customer CPEs (different unrelated households) in the 
same subnet with ethernet backhaul.

As long as there is only a single administrative entity per subnet, no 
security implications arise, just as you say.

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Mar 2009 14:14:47 -0700

> consider this totally broken network as a reason to add MSR RFC 4191 to

I think the model is to have a switch behind the CM so you wouldn't
need to congest the upstream.

Ole

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 27 Mar 2009 10:38:53 -0400

And I presume that switch also supports MLD so that the MAC filters
don't let multicast streaming video through to the service provider?

In the case that a low-end switch does not support MLD, it's still a
better practice to have the CPE Router be the first hop into the home.

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Mar 2009 12:10:38 -0400

Brain and others,

>standards; they apply them to their use cases.

For past two days or so, we couldn't understand what scenario was James talking about.  I and more folks thought one home to another home communications were being discussed but actually what James was looking at was a single home and this home's networking.  We also had a disconnect with James because it wasn't told to us that there was a hub sitting behind the broadband modem and then a CPE Rtr is behind the hub.  We assumed the CPE Rtr was directly connected to the broadband modem. Now that all things are clarified and we know it's one single home being discussed, we will look into common scenarios that Service Providers have in mind and take it from there.

Hemant

---

From: james woodyatt <[email-masked]>
Date: Fri, 27 Mar 2009 09:24:14 -0700

> better practice to have the CPE Router be the first hop into the home.

Yes, but most people setting up consumer gear in their home do not  
read IETF Best Current Practices RFCs before trying to plug the cables  
into the jacks on the sides of their boxes where the plugs more or  
less fit without hammering on them with whatever hard object they find  
at hand.

Some vendors of consumer gear seem to feel the need to make the  
process of connecting their various appliances together to comprise a  
functioning network into a university dissertation defense.  I think  
the more successful ones take a more subtle approach: they try very  
hard to make it as difficult as possible to connect devices together  
into a network that doesn't work.  When the links between the nodes  
are all CAT-5 cables with RJ-45 plugs on each end, that problem is non- 
trivial and shouldn't be hand-waved away as not worthy of attention.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Mar 2009 12:28:02 -0400

Barbara,

With your scenarios below, may I ask what are the things that the SPs
currently don't do well with IPv4? I see one problem mentioned - static
routes.  What are other problems?  Also, what node are you talking about
when you say "static routes in routing table"?  The host or the home
router?  I think you mean host, but still it good to make such things
clear.  If we get a list of all things that SP currently don't do well,
we can analyze the problems and see what we can do.  The scenarios you
have shown below are mostly already described in section 5 of RFC 4191.
That may lead one to think, RFC 4191 is a good match for such scenarios
and the scenarios' problems, but note one key feature of RFC 4191.  A SP
or a home user still has to configure the routing information on the CPE
router(s) before the routing is propagated to hosts in the home.  If
provisioning automation was an expectation in IPv6 over IPv4, RFC 4191
does not buy one that.  That is a separate orthogonal problem and SPs
have to prioritize it over other problems.  IMHO, more important
problems are to help host perform correct data forwarding in presence of
multiple routes available in the home.  

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2009 06:04:29 +1300

> For past two days or so, we couldn't understand what scenario was James talking about.  I and more folks thought one home to another home communications were being discussed but actually what James…

Yes, but if we conclude that it's desirable in general for
CPE routers to behave like routers on their upstream link,
AND if some ISPs don't want that, it should be a configuration
issue to switch such behaviour on or off. IMHO.

   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 27 Mar 2009 18:03:17 +0100 (CET)

On Fri, 27 Mar 2009, james woodyatt wrote:

> Some vendors of consumer gear seem to feel the need to make the process 
> of connecting their various appliances together to comprise a 
> functioning network into a university dissertation defense.  I think the 
> more successful ones take a more subtle approach: they try very hard to 
> make it as difficult as possible to connect devices together into a 
> network that doesn't work. When the links between the nodes are all 
> CAT-5 cables with RJ-45 plugs on each end, that problem is non-trivial 
> and shouldn't be hand-waved away as not worthy of attention.

The solutions I have seen (and I think makes most sense) is to have a WAN 
port on the home device. This is the way it works with most NAT routers 
today, they usually have a single WAN port and then for instance, 4 LAN 
ports.

I know some providers who offer 5 IPv4 addresses per customer and who 
support customer L2 switches being connected, with the downside that all 
traffic between these devices usually end up going via the ISP (because 
local-proxy-arp is used for security reasons). For this reason, most 
people hook up a NAT device anyway, to keep the speed up within their 
home.

So, even though I agree that there should be no artificial limitations 
imposed, the recommendation for the most scalable solution would be to 
only support single IPv6 address on the WAN side of the customer device, 
and require it to do routing and support DHCPv6-PD. This saves TCAM 
resources on the ISP device which otherwise have to keep adjacancy 
information for potentially a large number of customer devices.

My scenario above is what I envision for ETTH (also VDSL2 and other 
ethernet framed alternatives).

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Mar 2009 13:26:27 -0400

> From: Hemant Singh (shemant) [mailto:[email-masked]]

> routes.  What are other problems?  
<barbara> Static route configuration is a problem for scenario (1). It's
not that hard to do, but a simple automated method (like getting route
info from the RA of the access network router) would be preferable. In
scenario (3), the problem we see in IPv4 is that most hosts presented
with multiple DHCP servers off the same physical interface will just
take the first they see and ignore the rest. And these hosts don't know
how to figure out what to route to which "IP Gateway". There's really no
automated way in common IPv4 "home" usage to support multiple routers.
Sure, really knowledgeable people can do it, but not my brother or
neighbor. But they would like to be able to do it.</barbara>

> Also, what node are you talking about
> clear.  
<barbara> No, I meant the router. The SP has no ability to statically
configure the hosts, just the SP router. </barbara>

> If we get a list of all things that SP currently don't do well,
> does not buy one that.  
<barbara> Actually, RFC 4191 does help. That's why, in scenario (1), I
suggested the CPE router be able to accept routing info from the
received (on the WAN) RA. If the walled garden access network router
sends specific route info in RA (RFC 4191), then the CPE router can
receive that and put it in its routing table, and also send that route
info downstream to hosts, using RA (RFC 4191). Pure automation of the
process, for CPE Routers and hosts. </barbara>

Thanks,
Barbara
 
> particularly common in IPv4, and is handled through static routing

*****

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: "Stark, Barbara" <[email-masked]>
Date: Fri, 27 Mar 2009 13:37:19 -0400

> issue to switch such behaviour on or off. IMHO.

So, say something like "If the CPE Router is capable of behaving like a router on its upstream link, it MUST be possible to disable this behavior."?

This avoids the question of whether or not it's desirable (which we could probably argue endlessly), doesn't recommend the behavior, doesn't forbid the behavior, but makes sure the CPE Router can behave appropriately, when the WAN interface is connected to a service provider access network.
Barbara

*****

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: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Mar 2009 13:41:29 -0400

Brain,

We have thought about this from day one of our document. This is the sub-section we have in our Optional IPv6 features section.

[8.2.  Optional RIPng Support
The CPE Router may support RIPng routing protocol [RFC2080] (Malkin, G. and R. Minnear, “RIPng for IPv6,” January 1997.) so that RIPng operates between the CPE Router and the Service Provider network. RIPng has scaling and security implications for the Service Provider network where one Service Provider router may terminate several tens of thousands of CPE routers. However, RIPng does provide one solution from the CPE Router to the Service Provider network for prefix route injection.]

Hemant

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 1:04 PM
To: Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Operations; Wes Beebee (wbeebee)
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2009 06:45:43 +1300

> This avoids the question of whether or not it's desirable (which we could probably argue endlessly), doesn't recommend the behavior, doesn't forbid the behavior, but makes sure the CPE Router can b…

Agreed, and that is compatible with the RIPng text that Hemant just quoted.

   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Mar 2009 13:45:24 -0400

Barbara,

Such a thought has also been already captured in the CPE Rtr document - we agree with you.  See section 3.1 of Conceptual Configuration Variables, 4th bullet.  By default the document recommends if the device supports RIPng on the upstream WAN port(s), RIPng is disabled by default.

Hemant

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Friday, March 27, 2009 1:37 PM
To: Brian E Carpenter; Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Operations; Wes Beebee (wbeebee)
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

*****

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 27 Mar 2009 15:40:09 -0400

The new text for MSR's is as follows:

"8.7 Multi-homed Host Support (MEDIUM)
The CPE Router MAY support RFC4191 on its LAN interfaces.  Small
consumer embedded multi-homed hosts in the home may not have
configurable routing tables.  The CPE Router can communicate More
Specific Routes (MSRs) to these hosts to allow them to choose a
preferred router to send traffic to for traffic destined to specific
prefixes configured through manual configuration.  Advertisement of MSRs
through RAs is turned off by default."

- Wes

-----Original Message-----
From: james woodyatt [mailto:[email-masked]] 
Sent: Wednesday, March 25, 2009 7:17 PM
To: IPv6 Operations
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

I take it back.  It's interesting in the other cases as well.  Two CPE
routers attached to the same link will exchange their prefixes with MSR
advertisements regardless of whether the RAs from the service provider
have PIO options in them.  As they should.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 27 Mar 2009 15:56:47 -0400

James, 

Please note, we do not recommend that MSR be used to learn routes
between two routers in the home.  If there is more than one router in
the home, then we recommend RIPng be used.  Hopefully the text below is
clear that only when small consumer embedded devices exist in the home
and such devices multi-homed, then MSR use is recommended to be enabled
on the CPE Rtr.  Also

We got convinced because we found a use case where an IPhone is in the
home wireless LAN and also connected to AT&T's cellular network where
the phone downloads its favorite apps from an AT&T server but for other
access the phone may use the home wireless networks provided on a CPE
Router connected to the broadband modem.

Hemant

-----Original Message-----
From: Wes Beebee (wbeebee) 
Sent: Friday, March 27, 2009 3:40 PM
To: james woodyatt; IPv6 Operations
Cc: Hemant Singh (shemant)
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

- Wes

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Mar 2009 13:09:55 -0700

Hemant,
 
> The CPE Router may support RIPng routing protocol [RFC2080] (Malkin,
G. and R. Minnear, "RIPng for
> IPv6," January 1997.) so that RIPng operates between the CPE Router
and the Service Provider network.
> RIPng has scaling and security implications for the Service Provider
network where one Service
> Provider router may terminate several tens of thousands of CPE
routers. However, RIPng does provide
> one solution from the CPE Router to the Service Provider network for
prefix route injection.]

I don't see it as necessary to run RIPng when the CPEs act
as routers. If we are willing to allow the CPEs to establish
automatic IPv6-in-IPv4 tunnels across the provider network
to a default IPv6 router, then the CPEs can access the IPv6
Internet. If the default router knows of a more direct path
to the destination within the provider network, it can also
send an ICMP redirect. So, there is no IPv6 routing protocol
but the tens of thousands of customers still get to configure
their CPE devices as IPv6 routers.

This is exactly the VET model.

Fred
[email-masked]
 
> > For past two days or so, we couldn't understand what scenario was
James talking about.  I and more
> folks thought one home to another home communications were being
discussed but actually what James
> was looking at was a single home and this home's networking.  We also
had a disconnect with James
> because it wasn't told to us that there was a hub sitting behind the
broadband modem and then a CPE
> Rtr is behind the hub.  We assumed the CPE Rtr was directly connected
to the broadband modem. Now
> that all things are clarified and we know it's one single home being
discussed, we will look into
> common scenarios that Service Providers have in mind and take it from
there.

---

From: Mark Smith <[email-masked]>
Date: Sat, 28 Mar 2009 20:05:57 +1030

On Thu, 26 Mar 2009 17:53:05 +0100 (CET)

> I correctly interpret the scenario he proposed.

Yes it would defeat it. The only reason I can think of to require hair
pinning of traffic between downstream on-link peer CPE is if your
default router is your traffic billing point, and you want to bill
(count) the traffic between those CPE. Otherwise you're
probably unnecessarily forcing a P2P model connectivity model (i.e.
an ATM ADSL backhaul model) onto a multi-access technology (an
Ethernet/ADSL backhaul model).

Regards,
Mark.

---

From: Alastair Johnson <[email-masked]>
Date: Sun, 29 Mar 2009 01:40:54 +0800

> Ethernet/ADSL backhaul model).

Lawful Interception is another reason that a service provider may want 
all traffic from a subscriber aggregated to the default router.  There 
may be no way around this, depending on the LI requirements that are 
placed on the service provider, and where the logical interception point 
is (BNG vs. DSLAM).

aj

---

From: "Alan Kavanagh" <[email-masked]>
Date: Sun, 29 Mar 2009 21:05:41 -0400

Its fair to say that CPE Routers in general will not behave like routers
on their upstream link to the IP_Edge BNG node.

I would split this into two segments, a) The home CPE type Router and
b)Retail/Enterprise Router that is connected to two or more IP_Edge/BND
nodes. In case b) the use of some dynamic routing protocol would be
preferable and makes sense.

Alan K

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian E Carpenter
Sent: March 27, 2009 1:04 PM
To: Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Operations; Wes Beebee (wbeebee)
Subject: Re: draft-wbeebee-ipv6-cpe-router-04 comments

On 2009-03-28 05:10, Hemant Singh (shemant) wrote:
> Brain and others,
> 
>> If the broadband forum people don't want a use case with direct 
>> CPE-CPE communication, that's their choice, but we shouldn't 
>> artificially restrict this in the base spec for CPEs, IMHO. We write 
>> IPv6 basic standards; they apply them to their use cases.
> 
James talking about.  I and more folks thought one home to another home
communications were being discussed but actually what James was looking
at was a single home and this home's networking.  We also had a
disconnect with James because it wasn't told to us that there was a hub
sitting behind the broadband modem and then a CPE Rtr is behind the hub.
We assumed the CPE Rtr was directly connected to the broadband modem.
Now that all things are clarified and we know it's one single home being
discussed, we will look into common scenarios that Service Providers
have in mind and take it from there.

Yes, but if we conclude that it's desirable in general for CPE routers
to behave like routers on their upstream link, AND if some ISPs don't
want that, it should be a configuration issue to switch such behaviour
on or off. IMHO.

   Brian

---

From: "Alan Kavanagh" <[email-masked]>
Date: Sun, 29 Mar 2009 21:06:50 -0400

Yep, makes sense to me and that is what I also see :-)

Alan  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Templin, Fred L
Sent: March 27, 2009 4:10 PM
To: Hemant Singh (shemant); Brian E Carpenter
Cc: james woodyatt; IPv6 Operations; Wes Beebee (wbeebee)
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

Hemant,
 
prefix route injection.]

I don't see it as necessary to run RIPng when the CPEs act as routers.
If we are willing to allow the CPEs to establish automatic IPv6-in-IPv4
tunnels across the provider network to a default IPv6 router, then the
CPEs can access the IPv6 Internet. If the default router knows of a more
direct path to the destination within the provider network, it can also
send an ICMP redirect. So, there is no IPv6 routing protocol but the
tens of thousands of customers still get to configure their CPE devices
as IPv6 routers.

Fred
 
> >> If the broadband forum people don't want a use case with direct
CPE-CPE
there.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Sun, 29 Mar 2009 21:09:37 -0400

Correct, and this is why SP's are not too keen to have routing localised
in the aggregation network before the BNG. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alastair Johnson
Sent: March 28, 2009 1:41 PM
To: Mark Smith
Cc: Mikael Abrahamsson; [email-masked]; [email-masked]
Subject: Re: AW: draft-wbeebee-ipv6-cpe-router-04 comments

Mark Smith wrote:
> On Thu, 26 Mar 2009 17:53:05 +0100 (CET) Mikael Abrahamsson 
> <[email-masked]> wrote:
> 
>>> Normally the customers are separated from each other by split
horizont mchanisms and MAC adress translation techniques.
>> Yes, but that defeats the whole purpose of the proposal from Mark 
>> Smith if I correctly interpret the scenario he proposed.
>>
> 

> (count) the traffic between those CPE. Otherwise you're probably 
> unnecessarily forcing a P2P model connectivity model (i.e.

aj

---

From: Mark Smith <[email-masked]>
Date: Mon, 30 Mar 2009 20:18:05 +1030

Hi Alan,

On Sun, 29 Mar 2009 21:09:37 -0400

> in the aggregation network before the BNG. 

I'd have thought they should be keen to avoid that, unless all of their
customers are all under or likely to all under surveilence at the same
time!

The technical requirement of LI is that traffic has pass the
interception point. As the majority of people are honest, it seems to
me that optimising the topology to pass the interception point, rather
than for best throughput and lower latency, is wasteful, and an unfair
performance and ultimately a network capex and opex cost burden on
those subscribers who aren't under surveilence, and may never be. Only
traffic that is to be lawfully intercepted should be forced past this
interception point, if it doesn't already naturally traverse it.

Some topologies would inherently make the BNG the best traffic
interception point e.g. wholesale broadband aggregation via L2TP.
However, for other topologies (e.g. a single VLAN interconnecting
customers' ADSL routers, and an upstream default router for access to
the Internet/other services), traffic can travel direct between
subscribers / their CPE, as the CPEs have an on-link peer relationship.
Should lawful interception be required, either that on-link path could
be changed to traverse the interception point (e.g., by mechanisms
such as forced forwarding), or better yet, the interception point be the
suspect subscriber's point of interconnection i.e. the specific ADSL
service that they're using - as all their traffic is naturally going to
traverse that point.

If an SP wants to have a topology that has all traffic traversing the
BNG, or is forced to because of a legal requirement, that's fine.
My argument is that other SPs won't have this requirement so they
shouldn't also be forced to adopt this LI optimal topology - they
should have the freedom to implement a topology optimised for
throughput and low latency.

So, getting back to the discussion point, I think there would be
value in having a mechanism where downstream CPE can be informed of
on-link peer-CPE's assigned prefixes, without the CPE themselves having
to trust each other's announcements. An idea I had a while back was a
"prefix redirect", similar to an ND host redirect, issued by, and only
accepted from, the upstream on-link default router. Not quite as
optimal as the CPE themselves announcing their prefixes via a routing
protocol, but it would be more scalable - the CPE would only be
maintaining topological knowledge for destinations they're currently
using, rather than for all the destinations they can reach via on-link
peer CPE.

Regards,
Mark.

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 30 Mar 2009 10:08:02 -0400

My remembrance of why SPs aren't keen to localize routing is quite
different.
Originally, cable operators had neighbors all on the same Ethernet
network. Neighbors were able to discover each other's computers and
printers (this was before routers were common), and sometimes sniff each
other's traffic. This was considered a bad thing, from a customer
security and privacy standpoint. Telco providers decided that they did
not want to it this way, and effectively made Ethernet connections from
customers "point-to-point" to an element in the access network. 

Today, the access network elements are able to detect a lot of malware
traffic (especially DDoS attacks), and disconnect customers that are
infected with malware that presents a security / privacy /
performance-impacting risk to others. Unfortunately, this is not an
infrequent occurrence. If customer traffic were somehow able to bypass
these network elements, it would open up neighbors to attacks by
infected neighbors. That would be a very bad thing.

Furthermore, in general, there just isn't that much neighbor-to-neighbor
communication, that would make the savings outweigh the cost of
implementation. The only neighbor my home trades a lot of traffic with
(my kids and their kids, gaming) is on a separate network, since we use
different service providers.

Lack of cost justification and security concerns are the reasons why SPs
are unlikely to localize traffic within the access network, for general
consumers.
Barbara

> Behalf Of Mark Smith
> Sent: Monday, March 30, 2009 5:48 AM
> To: Alan Kavanagh
> Cc: Alastair Johnson; Mikael Abrahamsson; [email-masked];
> [email-masked]

*****

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 30 Mar 2009 11:20:56 -0400

Even if the SP doesn't have any ability to statically configure the
hosts, if an SP has a dedicated static IP address to a home, it is also
routine that the SP calls the home user and have the home user configure
anything static on the home PC including the IP address and any static
routes.  I personally went thru such a exercise with MCI/Worldcom for a
dedicated static IP address in my home via DSL seven years back.
Further, if any SP has more than one Internet connection to a single
home, then even if the SP cannot configure any host in the home, the
home user himself/herself has to configure various static routes to
selectively forward traffic out of the home via more than one Internet
connection.  That is the whole point of the discussion that if an SP
gives a home more than one Internet connection, the hosts in the home
would also have to have configure the selective routes - statically or
if IPv6 is used, one tool is MSR.  

Hemant

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Mar 2009 08:44:15 -0700

Mark/Alan,

> From: Mark Smith
[mailto:[email-masked]]
> Sent: Monday, March 30, 2009 2:48 AM
> To: Alan Kavanagh
[email-masked]
> interception point, if it doesn't already naturally traverse it.

I don't mind keeping all flows from CPE_1 to CPE_2 going
through the provider's default router, and that is in fact
a perfectly legitimate deployment scenario for VET. But,
if we want CPE_1 to CPE_2 route optimization, there needs
to be some way for them to establish a trust basis. 
 
> using, rather than for all the destinations they can reach via on-link

VET provides exactly such a mechanism. When CPE_1 gets
a redirect from the provider's default router, it can
send credentials (including proof of prefix ownership)
forward to CPE_2. In the reverse path, CPE_2 can send
its credentials to CPE_1. Sure, it's asymmetric - but
it gets the job done.

Fred

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 30 Mar 2009 13:40:00 -0400

Alan,

I don't understand your case (b) below.  If a single CPE Rtr in case (b)
is connected to, say, two different L3 first hop addresses (on one or
more SP routers), since both WAN interfaces on the CPE Rtr reside in one
device the internals of the device can forward traffic between the two
WAN interface and the device LAN interfaces.  Why would we need routing
between internals of the device?  Sure, if more than one CPE Rtr device
resides in a single home, I have already said, the two CPE Rtrs in the
home should use RIPng to share route information.

Also, since we have already said RIPng is optional on the WAN interface
of the CPE Rtr, I don't know what else to say.  If a deployment does not
want to use RIPng between the CPE Router WAN interface and the SP, that
is already included in the CPE Rtr document.  The same document also
discusses using RIPng on the WAN interface has scaling implications on
the SP L3 edge facing the home.  So the email Fred said about thousands
of devices is already something that I have replied to.

Hemant

-----Original Message-----
From: Alan Kavanagh [mailto:[email-masked]] 
Sent: Sunday, March 29, 2009 9:06 PM
To: Brian E Carpenter; Hemant Singh (shemant)
Cc: james woodyatt; IPv6 Operations; Wes Beebee (wbeebee)
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

Alan K

---

From: "Alan Kavanagh" <[email-masked]>
Date: Mon, 30 Mar 2009 13:59:18 -0400

Yes, agree on this that is the other reason why Fixed Broad Band SP's
ensure traffic to seperated and all traffic is routed to the BNG and I
don't see this changing.

Alan 

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: March 30, 2009 7:08 AM
To: Mark Smith; Alan Kavanagh
Cc: Alastair Johnson; Mikael Abrahamsson; [email-masked];
[email-masked]
Subject: RE: AW: draft-wbeebee-ipv6-cpe-router-04 comments

> such as forced forwarding), or better yet, the interception point be 
> the suspect subscriber's point of interconnection i.e. the specific 
> ADSL service that they're using - as all their traffic is naturally 
> going
to
> So, getting back to the discussion point, I think there would be value

> in having a mechanism where downstream CPE can be informed of on-link 
> peer-CPE's assigned prefixes, without the CPE themselves
having

*****

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: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 30 Mar 2009 16:00:05 -0400

Barbara,

What initial cable standards deployment are you talking about where
clients in the home in cable modems or hosts behind the modems could
talk directly to another cable modem in a neighboring home?  For over 10
years, in docsis networks since docsis 1.0, I don't see such behavior on
a routed CMTS - this thread is also focused on routed networks because
at the DSL first hop IPv6 router, we have a routed network.  Also, what
you have said below about security or privacy was something that I sent
already on 03/26.  This is what I had said.  

"At this point I would like you all to see this text below that I and
Wes wrote in an expired draft of
draft-wbeebee-on-link-and-off-link-determination-01.txt.
[3.  Router Models

                           +-----+
                           |     |

                                 Figure 1.

Hemant

-----Original Message-----
Behalf Of Stark, Barbara
Sent: Monday, March 30, 2009 10:08 AM

---

From: Fred Baker <[email-masked]>
Date: Mon, 30 Mar 2009 13:17:36 -0700

> customers are all under or likely to all under surveilence at the same

ISP architectures are not designed around surveillance; they are  
organized for control. That said, if a subpoena comes in, the effect  
of surveillance is not supposed to be detectable by the surveillance  
subject. If routing suddenly changed, and especially if local  
connectivity that the surveillance subject was using disappeared, that  
would be a pretty major tip-off.

In case you're questioning the "control" aspects, the issue is  
primarily that an ISP offers services to its customers under an SLA,  
and is responsible to enforce the SLA. For example, if the are  
guaranteeing me, or making representations to me of, a specific  
bandwidth, they can't allow another customer to do something that  
prevents me from getting that amount of bandwidth. As a result, they  
will generally run traffic on networks they operate through equipment  
that enables them to have the level of control they need, and they  
reserve the right (as RFC 2309 suggests) to force top talkers to back  
off when necessary to make that happen.

---

From: "Stark, Barbara" <[email-masked]>
Date: Mon, 30 Mar 2009 16:51:15 -0400

Hemant,
I was simply clarifying the history of why telco SPs currently use
"point-to-point" Ethernet connections, because other emails had implied
it was for governmental eavesdropping purposes. I meant no insult, and
had no agenda, other than to explain that eavesdropping was not the
primary goal. Governmental eavesdropping, as a justification for
requirements, leaves a bad taste in many people's mouths, and is rather
unpopular. Security and privacy are considered worthy goals. I was
trying to turn the tone of justification from being negative
(governmental eavesdropping) to positive (security and privacy).

Although DOCSIS 1.0 did include support for encryption, in the old days,
many providers did not enable this security, and there were many
anecdotes of neighbors seeing each other's computers. The encryption
capabilities of DOCSIS 1.0 were just an option, and not mandatory.
Again, this is really old (10 years +) history; but this history was key
in driving telco service providers to architecting access networks that
did not have shared Ethernet links among customers. This isn't intended
as an insult or a slam against the cable industry. I haven't heard any
of these anecdotes in years, and have no doubt that cable access is
quite secure at this time. But history is history. Here is a website
that describes some of this old history, in case you're curious:
http://www.securityfocus.com/news/7977.

I do not see that this history has any impact on the draft. The
requirements, from my perspective, are sufficiently justified. Since
there doesn't seem to be a request for any changes to the draft, based
on this thread, I don't think it's a useful thread to pursue.
Barbara

> Sent: Monday, March 30, 2009 4:00 PM
> To: Stark, Barbara; Mark Smith; Alan Kavanagh

---

From: Mark Smith <[email-masked]>
Date: Tue, 31 Mar 2009 07:19:14 +1030

Hi Barbara,

On Mon, 30 Mar 2009 10:08:02 -0400
"Stark, Barbara" <[email-masked]> wrote:

(As a disclosure, I work for an SP with a reasonable sized ADSL
network with Ethernet backhaul, but I'm participating here in my own
time.)

> customers "point-to-point" to an element in the access network. 

It is useful to remember history, but it's not the situation today -
and we're talking about designs trying to suit today's and near
future situations and requirements.

I'm not sure about cable CPE, but all ADSL CPE these days is a router,
doing IPv4 NAT and firewalling, by default, although they can usually be
configured to act as a bridge. While the bridging capability for
existing CPE might be useful as a deployment option for IPv6, I think
eventually all IPv6 CPE will be routed. SPs will probably in effect
demand it, because it makes it easier to scale subscriber counts within
the same part of the network topology.

> infected neighbors. That would be a very bad thing.

So, is their any reason why that functionality must be located in the
BNG?

Alan's company already make ADSL DSLAMs that perform an amount of IP
based traffic processing, despite them not participating in the IP
forwarding process. I'm guessing a lot of the DPI boxes don't
participate in IP forwarding either, so in the least, they don't show
up in traceroute output. It's all layer violations of course, but that
seems to be being more accepted for security / traffic policy
enforcement reasons today (e.g. RA guard, DHCP snooping/modificaton on
switches/ADSL DSLAMs etc.)

> different service providers.

Peer-to-peer traffic e.g. bittorrent etc., is a strong candidate for
network locality. The only thing that doesn't seem to exist
is P2P applications that make network topology aware peer selection,
and I think the IETF are already working on that. Once they exist, I
think there will be considerably more local intra-SP traffic than there
is today. 

> are unlikely to localize traffic within the access network, for general

Maybe this is what we're tripping up on. Different topologies and
network densities have different optimal forwarding paths. If the BNG
is colocated with the broadband layer 2 infrastructure in an exchange /
central office, then the overhead of traffic being forwarded via the
BNG, albeit increased, isn't all that significant. However, if the BNG
is located at some more central aggregation point, then having traffic
that can stay within the exchange/C.O. by e.g., going direct between
customer CPE at layer 2, saves both BNG resources and sometimes
significant backhaul bandwidth costs. That might not be a significant
cost today, but once P2P app become (layer 3) topology aware, I think
that'll increase significantly the amount of traffic that will be
being unnecessarily hair-pinned via an off-site device. 

Regards,
Mark.

> > the

---

From: Mark Baugher <[email-masked]>
Date: Mon, 30 Mar 2009 14:15:37 -0700

> talk directly to another cable modem in a neighboring home?  For  

What she says is true but it was a long time ago, in my experience.  I
remember @home sending an advisory to its customers in the 90's advising
them to change Windows 95 settings so their neighbors would not
be able to view their shared folders.

Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 30 Mar 2009 17:47:54 -0400

Mark,

>be able to view their shared folders.

Sure, I don't disbelieve Barbara.  All I was saying is that a routed
CMTS network will never have this problem and Cisco, for one, has always
built only a routed CMTS.  Before docsis 1.0, there were bridged CMTSs
or even after Docsis 1.0, if a CMTS was only a bridged CMTS, this
problem would arise.  However, the subject of our IETF thread is a
routed IPv6 network at the first hop of the SP which is a CMTS for cable
and BNG for DSL. There may be other DSL models where some other device
is the first hop and not the BNG, but the point of our discussion is the
first hop IPv6 router and any interactions between this SP router and
the home CPE Rtr. 

Hemant