RE: Posted a new copy of CPE Rtr draft

["Hemant Singh (shemant)" <shemant@cisco.com>]

Iljitsch,

Sorry for the delayed reply - as you know I was out on vacation to India
for a month and got back to work on August 3, 2009.  I am finally
catching up with all my emails.  Thanks much for the review.  I and Wes
discussed your questions and have responses ready.  Please see our
replies in line below.


>-----Original Message-----
>From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
>Sent: Monday, July 20, 2009 12:07 PM
>To: Hemant Singh (shemant)
>Cc: IPv6 Operations; Wes Beebee (wbeebee)
>Subject: Re: Posted a new copy of CPE Rtr draft

>>On 6 mrt 2009, at 23:27, Hemant Singh (shemant) wrote:
>>
http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-04.txt
>>now v6ops-ipv6-cpe-router-00, right?

Yes.

>Not having read the subsequent discussion yet, here is my feedback:
>Most important issue:
>"The CPE Router may also support prefix sub-delegation."
>We should make this a MUST. I don't want to end up in the situation
where I get a crappy DSL IPv6 CPE from my ISP and I can't use my own CPE
because there is no subdelegation.

I agree with you.  If the WG agrees, we'd be happy to change this one to
a MUST.


>If that's too hard, then we must mandate the ability for ISP-provided
CPEs to run in bridge mode. (But then that CPE would probably still need
a global address for management.) Preferably the ISP->provided CPE would
go in bridge mode automatically when a more capable CPE is present. I
guess this could happen if the ISP-CPE receives a PD request.

Yes, since the home-CPE behind the ISP-CPE will not send RA upstream, I
think so too when the first time the ISP-CPE knows it has a home-CPE rtr
behind it is when the home-CPE issues a DHCPv6 SOLICIT with an IA_PD
option. I am not sold on the bridged mode yet.  We will have to discuss
this more later.

>In general, information is often repeated.

Some repetition is deliberate.  We can remove any other when we find any
of it.

>"A CPE Router is an IPv6 Node"
>I would think it's a router... Or do you guys mean that in addition to
being a router, it must also fulfill the node requirements? If so, may
want to say so explicitly here.

We didn't want to be any more specific that our existing text because
all we wanted to say was the device for baseline functionality is what
is specified in the IPv6 Node requirements (req) because the Node reqs
doc also specifies some router behavior.  Over the baseline of the IPv6
Node reqs, since the device is comprised of a router, bridge, and a
switch, the behavior and requirements get complex and such complexity is
what is dealt with in such a CPE Rtr draft. 

>"The WAN interface is preferred to be Ethernet encapsulated but it may
support other encapsulations such as PPP."
>What about ATM? (I used native IPv6 over ADSL = ATM with a Cisco
>826/827 for years.)

Sure.  We just gave PPP as an example.  ATM or Firewire, or what have
you, is still totally supported because we say any other encapsulation
besides Ethernet may be supported.  We can also remove the "preferred
Ethernet" case.

>"If no LAN interface is present"
>Then what is the function of the CPE?

>    Before the CPE Router is initialized, the device must have IPv6
>    enabled.  The CPE Router SHOULD support the ability to disable its
>    IPv6 stack.  The CPE Router also has the ability to block or
forward
>    IPv6 traffic to and from the router's LAN interface(s).  [RFC2669]
>    includes a MIB definition to block the IPv4 or IPv6 Ethertype in
the
>    upstream or downstream interface(s) of a device such as the CPE
>    Router.  Some portion of this MIB may need to be modified for use
>    with the CPE Router.

>This kind of detail has the potential to obscure the forrest with
largely unnecessary trees. On the other hand it's also not so detailed
that it fully specifies what an implementation is supposed to do. >But
different vendors are likely to have different opinions on that, anyway.
And if v6 can be disabled, why not v4?

We only added text discussing blocking of v6 traffic on the CPE Rtr LAN
interface(s) since we are putting together an IPv6 CPE Rtr specification
and not an IPv4 one.  However, since our paragraph above also mentioned
RFC2669, note that we say either of v4 or v6 can be blocked as shown how
in this RFC.

>"The CPE Router MUST support at least one of two WAN interface models,"
>It takes very long until the other shoe drops, would be better to just
say "numbered and unnumbered" and then start a new paragraph for the
discussion of the numbered model.

We have thrashed a lot on this sentence and after agreement from a lot
of folks that such a sentence exists.  I think it is fine to keep the
sentence as is because let a CPE Rtr vendor decide if they have to
implement both or at least one of the two WAN interface models.  After
all, after this sentence, the ensuing text does discuss the numbered and
the unnumbered models.  

>    In the Numbered model, the WAN interface acquires a global unicast
>    address (GUA) using a combination of SLAAC and stateful DHCPv6 for
>    IA_PD (no IA_NA) or uses only stateful DHCPv6 for GUA (IA_NA)

>So the CPE is required to support address assignment for its WAN
interface with both DHCPv6 and stateless autoconfig? I don't like that.

What we mean to say is the WAN interface can acquire a GUA using SLAAC
and then use stateful DHCPv6 to acquire an IA_PD because neither
stateless DHCPv6 nor SLAAC support obtaining IA_PD.  Also, if the WAN
interface acquires a GUA using stateful DHCPv6, then the WAN can request
both IA_NA and IA_PD in one DHCPv6 transaction set.  The IA_NA DHCPv6
option is related to obtaining the GUA.

>"A Loopback interface"
>I would say "assigning a stable global unicast address to a loopback
interface" so as to not confuse people who live in a host-based world
where loopback interfaces have ::1 as their address.

Perfect suggestion.  Here is the new text.
[Assigning a stable global unicast address to a loopback interface
(which can be used as a stable peering point for routing protocols or to
respond to the anycast address) is optional.]
For reference, the old text was:
[A Loopback interface (which can be used as a stable peering point for
routing protocols or to respond to the anycast address) is optional.]

>"The IA_PD is sub-delegated to the LAN interface(s)"

>I would say "/64 subprefixes of the IA_PD provided prefix are assigned
to a LAN interface or multiple LAN interfaces. If the IA_PD only
provides a /64 (which is NOT recommended) this prefix is assigned >to
one LAN interface."

We have already mentioned such text in our document.  Could you please
look in the Cascading Routers section.

>"Either the Loopback or the LAN interface can be used to source WAN-
facing traffic."
>Like what? (I guess NTP or something like that...)

Oh, this is any traffic from the LAN in the home that needs to head out
the WAN interface to the SP.
>"if the O bit is set in the RA, the WAN interface acquires other
configuration information."
>What if the O bit is not set? Doesn't the CPE always initiate stateful
>DHCPv6 in order to obtain a prefix?

A delegated prefix or the IA_PD can only be requested using stateful
DHCPv6.  M and O bits is contentious in the 6man and elsewhere, but if
the M bit is set, supposedly the network has a stateful DHCPv6 server
that clients can obtain IA_NA or GUA from using stateful DHCPv6.
Stateful DHCPv6 acquires the Other information as well such as IPv6
address of the DNS server. If the O bit is not set, and if the WAN
interface has obtained GUA using SLAAC, then stateless DHCPv6 is
initiated to get Other information since the M-bit is set in the RA.


>"Other IPv6 configuration information is obtained using stateless
DHCPv6."
>I don't think it makes sense to perform both stateful and stateless
DHCPv6.

Yes, it does.  See my responses above.

>"The Unnumbered model is incompatible with the strong host model
[RFC1122] on the CPE router"
>Which is irrelevant, the CPE is a ROUTER, and there are no "strong"  
>routers, only "strong" hosts.
>"where a device that uses the strong host model can operate as a CPE
Router."
>Such devices must not be allowed.

NTT in Japan already has such devices deployed.  Please look in v6ops
archives for the CPE Rtr document and search for Shin M. who asked for
such text to be put in the CPE Rtr.  They are using Windows PC with
their own hacked up router code.

>"The CPE Router may include a stateful DHCPv6 server to assign
addresses to home devices connected via the LAN interface(s) of the CPE
Router."
>That seems rather pointless. And because it's only a MAY there's no
need to specifically point this out in the text.

If one gets to the CPE Rtr next section related to Cascading of routers,
then one can see why a DHCPv6 server is needed and also a MAY.  You see,
to cascade CPE Rtrs one needs either a DHCPv6 server in the CPE Rtr or a
DHCPv6 relay. 

>But I guess this means that DHCPv6 requests done by hosts on the LAN
side are never propagated to the ISP?

All DHCPv6 requests between a client and server terminate at the server,
so the client DHCPv6 reqs are not expected to propagate to the ISP.

>"The home devices can also acquire addresses via SLAAC."

>That's not very specific. Needs to be: the CPE MUST send router
advertisements with a prefix option once a prefix is available.

Not quite.  What if the LAN wants to do DHCPv6 and not SLAAC.  I think
we can make the SLAAC as default and allow a configuration change to
change SLAAC to DHCPv6.

>    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).

>Need to explain that the old and the new prefixes must overlap for some
time to allow for graceful renumbering.

Both RFC 4862 and 4861 mention graceful renumbering.  We can add a
sentence to our document saying to keep graceful renumbering in mind or
maybe not...

>    This document recommends the RA sent out by LAN Interface(S) to be
>    configured for SLAAC so that the prefix advertised in the RA is
>    derived from the IA_PD assigned to the CPE Router by the Service
>    Provider;

>Requires

>    the O-bit is also set so that the CPE Router can pass
>    Domain Name Server(s) IPv6 address(es) to home devices.

>Only if the CPE implements a stateless DHCPv6 server that redistributes
the DHCPv6 info the router itself got from the ISP, or if the router
acts as a DHCPv6 relay.

Or the CPE Rtr has a stateful DHCPv6 server which can dole out Other
parameters.

>How are ULAs for configuration supposed to work? Obviously you can't
print the address for configuration in the manual (it being randomly
generated and all). So at the very least this has to work >through the
DNS. The problem is: how do you get rid of the ULA addresses on hosts
once global addresses are available?

Please see archives of v6ops for the ULA discussion that closed the ULA
issue by agreeing with us to keep ULA permanent on the CPE Rtr.  So the
ULA is not going away if the GUA is acquired.  That is why in section
5.5.1 we mention source address selection.  As for DNS, since it's a
local DNS server in the CPE Rtr the local DNS will return entries for
both the GUA and the ULA.  


>The only time ULAs outperform link locals is in the case of cascaded
CPEs where you want to go from host X to CPE A through CPE B. With link
locals that wouldn't work.

>An alternative for the configuration address would be a well-known
address, so users can be told to go to 2001:db8::1. This could work with
link locals on the hosts as long as CPEs aren't cascaded.

Rather than use any well-known address, we have proposed
http://router.local in section 8.4.  By definition of Bonjour is limited
to the link-local domain.


>    initiates L2TPv2 tunnel from
>    the CPE Router to tunnel IPv6 data from the home over an IPv4
>    network.  The feature is enabled before any IPv6 host in the home
is
>    connected to the CPE Router or the WAN interface of the CPE Router
is
>    operational.

>What does this mean?

Section section 3.1.1, Figure 1 of the softwires draft referenced in
this section.

>It is important that delays or failure with the softwire stuff doesn't
delay the initiation of native IPv6.

Sure.  Now that this whole section has moved to our "bis" CPE Rtr
document, we have just referenced the DS-Lite draft which is turn
discusses softwires etc.  Any failures with softwire has to be discussed
in the softwire draft.  Please note, after the San Francisco IETF in
Spring 2009, it was decided in the v6ops WG that our draft be broken up
into two drafts.  The first document would only discuss tech already in
RFC form and/or mature tech so that the document could be expedited in
the IETF RFC process.  A second document (which I refer to as the bis
draft) tracks all the Work In Progress including DS-lite, softwires,
etc.  We will submit the bis version as an individual submission to the
IETF sometime this week; we will also submit a new version of the Phase
I draft alongwith it.


>Also, "softwires" is the IETF wg, please use the name of the protocol.

So far I have not seen the name of the protocol related to softwire.
Even DS-lite that mentions it uses the term softwire.  I will double
check with folks and if a formal name exists, we will replace the term
softwire in our document(s).  

>Why is this under the PPP heading?

See Figure 1 in section 3.1.1 in
http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l2tpv2-13#se
ction-3.1
Softwire is using PPP for some control.  However, now this softwire
section is gone to the bis draft and trimmed down for text as well.


>5.7.  Stateful DHCPv6 Server (CORE)

>    The CPE Router may support a stateful DHCPv6 server to serve
clients
>    on the CPE Router LAN interface(s)

>Core but not a requirement???

The reason is because one may be able to get by with just a DHCPv6
relay. 

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

>(see above). Having a server or a relay are very different for the ISP,
not good to leave both options open because now the ISP has to support
both.

Valid point.  We do want to change the DHCPv6 server to a MUST if the WG
has no objection.


>Is it mentioned anywhere that if a CPE supports subdelegation, it must
also be capable of installing routes towards the router that has a
subdelegation?

The Cascading routers section has following text:
[The CPE Router MAY support RIPng in the home network.]
If not RIPng some simple static routes are easy to auto-provision as
addresses are doled out to downstream clients.  We can add a sentence
towards this effect.

>"The CPE Router MAY support RIPng in the home network."

>For what purpose? RIP is a terrible routing protocol...

We have legitimate requirements from the community that the home may
support more than one routers connected to more than one ISP domain.
For example, one router is connected to a cable modem and the other
router is connected to a DSL modem.  For these two routers in the home,
RIPng is suggested. A future version of this document will include use
cases and such a two router case makes sense to add for a use case.

>    Each of the WAN and LAN interface(s) of the CPE Router must have
its
>    own L2 (e.g.  MAC) address.

>Why? This may make vendors limit the number of interfaces.

Number of interfaces is not limited.  Router vendors implement virtual
network interfaces via software over the hardware network interfaces.
Each of WAN and LAN interface is a hardware port with a hardware address
on the CPE Rtr.  Over any one hardware address, numerous software
network interfaces could be developed.

>"The CPE Router supports ND protocol"

>the ND protocol

>    both the WAN interface and LAN interface(s) to advertise itself as
a
>    router to neighbors in the Service Provider and home networks.

>You mean it sends RAs on the WAN side? Why???

On the WAN side, the CPE Rtr sends an RS.  We will reword this sentence
to:
[The CPE Router supports ND protocol on both the WAN interface and LAN
interface(s) and sends Router Solicitations (RS) on the WAN interface
and sends Router Advertisement(s) (RA) on the LAN interface(s).]


>    If the CPE Router has only one /64 prefix to be used across
multiple
>    LAN interfaces and the CPE Router supports any two LAN interfaces
>    that cannot bridge data between them because the two interfaces
have
>    disparate MAC layer, then the CPE Router MUST support ND Proxy
>    [RFC4389].

>No, This will just be used as a reason for ISPs to give users less than
a /64. If they do that, simply configure 1 LAN interface, no special
case handling.

>"Legacy 3GPP networks have the following requirements:"

>I think it would serve the document better to keep such unusual cases
out of it.

Please discuss with Nokia and Teemu who is also working with Qualcomm -
they wanted such a section to full their needs from this document.  This
document is defining a generic IPv6 Rtr that can be used in any
deployment, so why not let the legacy 3GPP folks use this document.
Just by adding a ND Proxy section to this document fulfills their needs.
We have taken special care in this section to clearly say, please use ND
Proxy only under this legacy 3GPP deployment.


>    For these legacy 3GPP networks, the CPE Router MUST support ND
Proxy
>    between the WAN and LAN interface(s).  However, if the CPE Router
has
>    multiple prefixes available for use on LAN interfaces(s), then ND
>    Proxy is not necessary.

First a MUST and then "not necessary" is far from ideal specification
writing...

Does the change of the sentence beginning with "However" above looks
better to you:

[If a CPE Router will never be deployed in an environment with these
characteristics, then ND Proxy is not necessary.].


>About multicast: what happens on wifi, which can't handle non-minimal
amounts of multicast traffic? (Also see the multicast discussion on the
homegate list.)

We have not discussed wifi in the CPE Rtr yet.  Yes, I have seen the
mcast discussion on the homegate list where folks are talking above
converting the traffic to unicast or bcast?  We have to see what is
mature tech here to add to the CPE Rtr document if the community agrees.

>    If the CPE Router hardware includes a network bridge between the
WAN
>    interface and the LAN interface(s), then the CPE Router MUST
support
>    MLDv2 snooping as per [RFC4541].

>Can't it just treat multicasts as broadcasts? That's why cheap switches
do AFAIK. I would rather not have MLD snooping, because if implemented
incorrectly it breaks the network in severe ways. (Like >boxes that
didn't pass IPv6 multicasts because of IGMP snooping.)

If there are issues/bugs with MLD Snooping, it's a bug.  Anyhow, one has
to take that up with the IETF mcast groups that discuss MLD Snooping
protocols.  

>"8.1. Path MTU Discovery Support (MEDIUM)"

>Why medium? This is absolutely essential to avoid PMTUD black holes,
one of the scurges of today's internet in general and the IPv6 internet
in particular. The language here MUST be much sharper.

The reason for the MEDIUM designation was to indicate that work is
ongoing on this subject and the industry has not yet reached consensus
on the right way to address this.  It's not an indicator that the work
is not important - to the contrary, we agree that the work is very
important.


>"Ethernet Jumbo frames (9000+ bytes)"

>Jumboframes is anything bigger than 1500 bytes.

Sorry, it's a mistake.  Will change to (> 1500 bytes).

>    The CPE Router may support RIPng routing protocol [RFC2080] so that
>    RIPng operates between the CPE Router and the Service Provider
>    network.

>Have you talked to ISPs about this? Not only is RIP slow, it's also
insecure. I don't think they want this headache. And what if the ISP
redistributes 50000 prefixes from other customers to the CPE?

We are talking to ISPs and also in this mailer.  ISPs do not like using
RIPng but we would like to point out that if RIPng is not used then how
does the SP network know of delegated prefix routes?  IETF has seen a
few proposals on this PD route injection but none of the proposals have
any traction yet - I have not seen any RFC on this subject. That is why
we say in our draft
[However, RIPng does provide one solution from the CPE Router to the
Service Provider network for prefix route injection]

>Besides, "MAY" is useless. If 99 CPE vendors support RIP and 1 doesn't
then the ISPs still can't use it.

We hear you on the MAY's.  However, note, the MAY's are due to some
decisions not made in the IETF for how certain things are going to work
in the residential broadband network.  Some time is needed for things
like a route injection to gestate and we cannot treat route injection as
a future item - it's a problem that needs to be solved for a delegated
prefix network.


>"The firewall may"

>Again, "may" language is useless. There must be a list of the extension
headers that firewalls must support.

The extension headers is still Work in Progress.  Anyway we have
referenced the Woodyatt CPE simple security draft that should deal with
any such firewall issues. This section has also moved to our bis draft.


>"CPE Router MAY initiate ISATAP"

>How would that work??

The CPE Rtr must always try 6rd first and if that fails then the rtr
should try 6to4 and once that fails, then I think it makes sense the
device can try ISATAP.  Either one has the ISATAP PRL manually
provisioned on the rtr or ISATAP queries for the PRL with DNS.  I am
personally not sold on ISATAP at all, but Fred Templin asked for ISATAP
to be included in the CPE Rtr.  If others in the community do not want
ISATAP in the CPE Rtr, then we can remove it.

 >   softwires.  Further, any approach which requires the use of a
tunnel
 >   MUST take into account the reduced MTU.

>Would be useful to include an MTU option in RAs that reflects the
usable maximum packet size on the WAN side.

RFC4861 already mentions such a fact in section 4.2 with the RA MTU
option.

>"An AAAA record is relayed to the server."

>This sentence doesn't make any sense.

>Please refer to the DNS64 document, a CPE either needs to do it right
or not do it at all.

This section has been reworked for the two new documents.  DNS64 bagnulo
draft is now mentioned in the bis document.

Hemant