

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.

Kindest regards,

Arifumi Matusmoto

> 
> Best regards,
> 
> Haibo
> 
> 
>> -----Original Message-----
>> From: Arifumi Matsumoto [mailto:[email-masked]]
>> Sent: 2006年6月9日 19:12
>> To: [email-masked]
>> Subject: Re: questions about draft-wen-ipv6-rsra-opt-multihoming-00
>>
>>
>> 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.
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

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