Subject: Re: RE: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00

From: Greg Daley <[email-masked]>
Date: Wed, 07 Jun 2006 08:47:58 -0400

Hi Wen, 

> 802.21 is developing standards to enable handover and 
> interoperability between heterogeneous network types including both 
> 802 and non 802 networks. 802.21 is running below IP layer. 
> However, SAAC procedure is running in IP layer.

802.21 is designed to run over L3/L4 transport.  

So while it provides link-layer (and upper layer) related information,
it's not restricted to a single link, and routers may participate
in its conversations.

> You know, in multi-homing site, each router will advertise RA which 
> containsIPv6 prefix information, and the interface of host will 
> receive all this RA. The 
> standard Stateless Address Auto-Configuration doesn't provide extra 
> information to help prefix selection. Multi-homing informaiton 
> option is for this purpose.

Please see below.  I don't agree this is the right place to do it.

> > With respect to access network related configuration information,
> > we already have DHCPv6 for that, and more specific route options
> > for Router Discovery.
> In IPv6, there are two ways for address auto-configuration, i.e., 
> statefulconfiguration based on DHCPv6, and stateless configuration. 
> It seems there is
> no standard that says only DHCPv6 can be used in access network and 
> SAAC is forbidden.

I'm not indicating that DHCPv6 should be used for address configuration,
I'm indicating that this information is "Other Configuration" such
that even a Stateless DHCPv6 could be used (for example, with O=1
advertised in the RA).

This is probably the correct location, as DHCPv6 is more extensible
than Router Discovery.
 
> > Router Discovery is for prefix and next hop determination.  Let's 
> not> make it complicated for other reasons.
> More information along with prefix information option in RA, will 
> help host select the appropriate prefix to form its IPv6 global address
> and also select its exit router. It's not trying to make things
complicated.
> Without this effort, host cannot find the appropriate prefix and exit
router.

This is only partially correct.  RFC 4191 already defines which router
can be used for a particular destination prefix.

http://www.ietf.org/rfc/rfc4191.txt

With regard to a particular source prefix, it's already been discussed
that IPv6 router discovery doesn't tie particular IPv6 Prefix information
options to particular routers, by design.

That is, a prefix learnt from one router may be used as source address to
send a packet to any of the default routers on the link.  The routers are
intended to determine which amongst them performs the forwarding.

Why can't this be left to the routers?

Greg

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Wed, 07 Jun 2006 09:49:33 -0400

FWIW, based on my skimming of the document, I think this is a bad
approach. Reasons:

1) the scenario is rather limited, a single link directly connected to
   multiple ISPs (through different routers). IMO, this is too
   limiting a scenario to develop a specifiic solution that doesn't
   address a other scenarios.

2) It places additional complexity in the hosts, and it is not clear
   to me that the benefits are sufficient. Indeed, it's not
   immediately clear what the "multihoming" aspect is. In my mind,
   "multihoming" means having multiple ISP connections, and actually
   using them simultaneously. The approach in the document seems to
   consist of "pick just one", which is not multihoming IMO. Or if it
   is "use multiple ones simultaneously", then the host needs to be
   sure to route packets to the right router based on the source
   adddresses used. That is signifificant (new) complexity and I am
   not at all sure we should be doing that at this point in time.

So, at this time, color me very skeptical to this idea.

Indeed, I'd prefer backing up a bit and having discussions about the
problem statement and what the actual problem is that needs solving.

Thomas

---

From: Lawrence Zou <[email-masked]>
Date: Thu, 08 Jun 2006 08:59:26 +0800

I am agree with Thomas's opinion.
It seems like some kinds of "ISP selection" rather than multihoming IMO
and places additional complexity in the hosts.

>-----Original Message-----
>From: Thomas Narten [mailto:[email-masked]] 
>Sent: Wednesday, June 07, 2006 9:50 PM
>To: [email-masked]
>Subject: Re: questions about draft-wen-ipv6-rsra-opt-multihoming-00
>
>
>FWIW, based on my skimming of the document, I think this is a 
>bad approach. Reasons:
>
>Indeed, I'd prefer backing up a bit and having discussions 
>about the problem statement and what the actual problem is 
>that needs solving.
>
>Thomas   
>

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 09 Jun 2006 20:11:46 +0900

Hi Wen,

Maybe, we are working on similar problems.
Let me comment on a few things about your proposal.

- I think Routing Header is an interesting method
  to implement policy routing at gateway. The problem
  is which router has to support Routing Header.
  Is it correct that L3 CPE and also ISP's edge router
  has to support Routing Header in scenario2 ?
  When you see the deployment status of IPv4 source
  routing, it is clear that ISP routers won't possibly
  support Routing Header for security reason or other,
  it may be possible to make CPE vendors to implement
  Routing Header support though.

- Even if ISP edge routers implement Routing Header support,
  how do the CPEs know ISP edge routers' IPv6 global-scope
  address ?
  If I remember correctly, in the Routing Header if you
  put a link-local-address, the packet's final destination
  must be a host on the same link.
  So, end hosts have to know a global address of L3 CPE
  and ISP edge routers.
  As RA and DHCPv6 are delivered by link-local addresses,
  there is no means to inform a global address of a ISP edge
  router or a L3 CPE.

- At the last e-mail sent to IPv6 ML, you mentioned that
  Host chooses an address given by an ISP that the host want
  to connect. IMO, however, your proposal doesn't have any
  effects on address selection at hosts, but have effects
  on routing after address selection. After address selection
  is completed, your mechcanism selects an appropriate next
  or next-next hop depending on the selected source address.

  We are now working on the address selection aspects of
  the similar environment considered here.
  http://www.nttv6.net/dass/draft-arifumi-ipv6-policy-dist-00.txt
  http://www.nttv6.net/dass/

  Now I'm revising this draft and also writing a problem statement
  document of default address selection in multi-prefix environment.

Best regards.