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

["Stark, Barbara" <bs7652@att.com>]

> From: Hemant Singh (shemant) [mailto:shemant@cisco.com]

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

*****

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