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

From: "CTO WEN Haibo" <[email-masked]>
Date: Thu, 8 Jun 2006 10:33:12 +0800

Hi Greg,

Thank you for your information.

 IEEE 802.21 considers handovers between the following technologies
- between 802.xx and 802.yy
- between 802.xx and Cellular (3GPP, 3GPP2)
- between 802.11 ESS
where x,y = 3, 11, 15, 16. 
I just read the first home page of 802.21, and haven't read through 802.21. So I'm
not very clear whether it is desigend to run over L3/L4 transport. I think it is mainliy
designed for handover, and once the handover is needed, there is an indication
for roaming terminal selecting new parameters from new network. It cannot solve
the problem in this multi-homing site, a LAN or subscriber network has two exit
routers which are connected two different ISPs,and the router implements ingress
filter.

RFC4191 is a good solution for exit router selection in multi-homing site. I hadn't 
noticed this RFC. Thank you. However, it seems it cannot help host implement 
source address selection. There are cases that a multi-homing site is connected 
to multiple ISPs, and the exit router (i.e., the edge router of ISP) implements ingress 
filter. The exit router will drop the packets sent by hosts with wrong source 
address, only the packet with source address in the assigned prefix space from the
a specified router will be routed by this router. Host needs to know which IPv6
address it should use to reach its desired service from the correct ISP. For example, 
subscriber networks are connected to IPTV provider and Internet service provider. 
The edge router of each provider will advertise its own prefix information, and if
and only if the terminal in this subscriber network uses the prefix advertised
by IPTV provider's edge router as its source address, it can obtain its desired 
IPTV service.

Haibo

> -----Original Message-----
> From: Greg Daley [mailto:[email-masked]]
> Sent: 2006年6月7日 20:48
> To: CTO WEN Haibo
> Cc: [email-masked]
> Subject: Re: RE: RE: questions about
> draft-wen-ipv6-rsra-opt-multihoming-00
> 
> 
> 
> 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: "CTO WEN Haibo" <[email-masked]>
Date: Thu, 8 Jun 2006 12:08:15 +0800

Thomas,

Thanks for your comments.

I'll explain this for you.

(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."
   
The mutihoming option used along with prefix information optin just
give some extra information for host/terminal to select the appropriate 
prefix to form its IPv6 global address. This is not required that the a 
single link directly connected to multiple ISPs (through different 
routers). For example, in the following figure,logically the subscriber
network is a multi-homing site, it obtains different prefix from 
different ISP networks. Router 1 (or home gateway) may obtain these 
prefixes from the two ISPs via DHCP-PD, and router 1 is responsible for 
advertising the prefixes information through RA. Multi-homing 
informaiton option is advertised along with the corresponding prefix 
information option, thus host/terminal can choose correct prefix to form
its global address.
Edge routers of ISPs normally implement ingress filter. We assume ISP1
provide IPTV to the STB. Without multihoming option, STB in the 
subscriber network doesn't know how to choose prefix to form its IP
address. If it forms its source address from the prefix from ISP2, it
cannot obtain the desired IPTV service from ISP1.

         ____________________     ____________________  \
        /                    \   /                    \  \
       |  ISP1 core network   | |   ISP2 core network  |  \
        \__________ _________/   \__________ _________/   |
                   |                       /              | ISP
                   |                      /               | networks
                   |                     /                /
           +-------+-------+     +-------+-------+       /
           | edge-router 1 |     | edge-router 2 |      /
           +-------+-------+     +--+----+-------+ 
                    \              /                   \
                     \            /                     \
                    +------+------+                       | 
                    |  router 3   |                       |
                    +------+------+                       |aggregation
                           |                              |& access
                    +------+------+                       |network
                    |  router 2   |                       |
                    +------+------+                       |
                           |                             /
                           |
                    +------+------+                     \
                    |  router 1/  |                      \
                    |home gateway |                       \
                    +------+------+                        | Subscriber
                           |                               | network
              +------------+--------------+                |
              |            |              |                |
        +-----+----+  +----+-----+  +-----+----+          /
        |   host1  |  |   host2  |  |   STB    |         /
        +----------+  +----------+  +----------+        /

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

Multihoming information option is to add more information to the 
advertised prefix information option. Host/terminal will receive all the
prefixes and related information (e.g., the ISP who allocates the prefix
). Host may cache all these information, when it want to visit some
services of one specified ISP, it will use the address from that ISP and
also use the corresponding exit router (if the single link is directly 
connected to the exit router). These information may be transfered to
applications to do selection. "use multiple ones simultaneously" may be
more used by PC.
In fact, in IPv6 access network, there are some terminals that just 
wants to special services from special service provider. For example,
if STB is only binded to IPTV service, so it can just "pick just one", 
i.e., select one desired prefix.
The "scenario" maybe should be called "example", which just shows how to
use this option with prefix infomraiton option.

Further comments are very appreciated! Many thanks.

Best regards,

Haibo

 <<response to Thomas (draft-wen-ipv6-rsra-opt-multihoming-00).txt>> 

> From: Thomas Narten [mailto:[email-masked]]
> Sent: 2006?6?7? 21:50
> 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:
>
> 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: "CTO WEN Haibo" <[email-masked]>
Date: Tue, 13 Jun 2006 09:35:47 +0800

Hi,

> From: Arifumi Matsumoto [mailto:[email-masked]]
> Sent: 2006年6月12日 16:18
> > 1. "routing header" issue
> > In the RFC4292, it says "The Internet Protocol Version 6 is 
> specified in
> > [RFC-2460].  This specification MUST be supported." So IPv6 
> router MUST
> > support Extension Headers including routing header. Due to the 
> > simplified header and good orgnized structure of extension 
> header, IPv6 
> > router can process IPv6 header with extension headers much 
> > faster than IPv4 router process IPv4 header with many options.
> 
> Do you mean RFC4294 "IPv6 Node Requirements", right ?
> As in section 4.1 of RFC4294, it is still disputable
> that Routing Header support should be "MUST". I am
> dubious about RH support in networks like ISP considering
> Source Routing support status in IPv4.
> 

Multihoming Informaiton option just provide an method to advertising
edge router's address along with the corresponding prefix if needed.
Whether this RH will not be supported by router is beyond this document.
In my opinion, for access network when scenario 2 in this document is 
deployed, only L3 CPE and edge router should support this feature for 
fast forwarding/policy routing.

> > 2. "how do the CPEs know ISP edge routers' IPv6 
> global-scope address"
> > In scenario2, the L3 CPE (or the router in the subscriber network) 
> > will obtain a prefix from an ISP. The method of obtaining prefix 
> > will be done by DHCPv6 Prefix Delegation (PD). ISP edge router's  
> > IPv6 global-scope address may be obtained by CPE along with the with
> > the DHCP-PD procedure or other
> > method (after all, L3 CPE is connected to the ISP edge router).
> 
> I just wanted to know if there is a standardized way for this or
> there is a way for CPEs to get edge routers' addresses without
> any additional irregular changes to edge routers.

Irregular changes? No.
I haven't yet made a detailed investigation on whether there is a 
standardized way for this. But IPv6 Prefix option for DHCPv6 contains 
IA_PD prefix option, which has IAprefix-options field. This field is 
used to carry options associated with this prefix. Carrying an IP 
address here can be done.

> 
> > 3. "address selection at hosts"
> > The objective of this document is to propose a new option for RS/RA 
> > message. Multi-homing informaiton option is just to add some extra 
> > information to prefix information option in RA. These extra 
> > information will help host to do correct prefix selection, source 
> > address selection and exit router selection. For example, STB may 
> > only selectthe prefix from the "IPTV" service provider to form its
> > global IPv6 address. PC may select multiple prefixes to form its
> > address, at the same time it will
> > cache the information with the related prefix (/address), these 
> > information will help it select correct source address and so on.
> 
> About this point, I was talking about the implementation aspect.
> Making STBs to support this option seems fine, perhaps you don't
> need standardization though.
> For PCs, address selection rule is defined in RFC3484. If you
> change the existing address selection rules, I wondered what
> kind of the changes will be made.

Multihoming information option is just trying to provide more 
information for each prefix in RA, these information will and can help
host/terminal select correct prefix/source address/exit router in 
multihoming environment. It doesn't damage exiting address selection 
rule. It seems exiting rule haven't considered that the edge router may
implement ingress filter.

Best regards,

Haibo

> >> From: Arifumi Matsumoto [mailto:[email-masked]]
> >> Sent: 2006年6月9日 19:12
> >> To: [email-masked]
> >> 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.
> >>
> >>
> >>
> >>
> >> 
> >> Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6
> >> 
> --------------------------------------------------------------
> ----------
> >>
> >> 
> >> Administrative Requests: 
> https://www1.ietf.org/mailman/listinfo/ipv6
> >>