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

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

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

-----Original Message-----
From: Stark, Barbara [mailto:bs7652@att.com] 
Sent: Thursday, March 26, 2009 3:38 PM
To: Hemant Singh (shemant); james woodyatt; IPv6 Operations
Cc: Wes Beebee (wbeebee)
Subject: RE: draft-wbeebee-ipv6-cpe-router-04 comments

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

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