Subject: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools

From: Fortune HUANG <[email-masked]>
Date: Tue, 08 Jun 2010 10:30:00 +0800

Dear all,
 
In section 3 of RFC4862 (SLAAC), it states as follows:
"   o  A large site with multiple networks and routers should not require
      the presence of a DHCPv6 server for address configuration.  In
      order to generate global addresses, hosts must determine the
      prefixes that identify the subnets to which they attach.  Routers
      generate periodic Router Advertisements that include options
      listing the set of active prefixes on a link."
 
My question is how the host determines the prefixes allocated from different
prefix pools?
 
For example, suppose we have two prefix pools, one for the IPTV service and
the other for the HSI service.
For a specific link with a PC for the HSI service and a STB for the IPTV
service,  the router generates the Router Advertisements with two active
prefixes allocated from the two different pools. 
1) Will the STB accept both prefixes and generate two global addresses?
1) Or the STB will accept only the prefix allocated from the prefix pool for
IPTV? 

Best regards,
Fortune

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Tue, 8 Jun 2010 10:27:05 +0530

Fortune,

As per RFC 4862 "section 5.5.3. Router Advertisement Processing  of RFC" 
STB should generate two global addresses.
Please note  Prefix Information Option in Router Advertisement does not contain a way to associate a prefix with a service.
DHCPv6 will be a better option to request an IPv6 address/prefix for a particular service.

Any particular reason for preference to use RA over DHCPv6 ?

--
Shree

From: [email-masked] [mailto:[email-masked]] On Behalf Of Fortune HUANG
Sent: Tuesday, June 08, 2010 8:00 AM
To: [email-masked]
Subject: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools

Dear all,

My question is how the host determines the prefixes allocated from different prefix pools?
 
For example, suppose we have two prefix pools, one for the IPTV service and the other for the HSI service.
For a specific link with a PC for the HSI service and a STB for the IPTV service,  the router generates the Router Advertisements with two active prefixes allocated from the two different pools. 
1) Will the STB accept both prefixes and generate two global addresses?
1) Or the STB will accept only the prefix allocated from the prefix pool for IPTV? 

Best regards,
Fortune

---

From: Fortune HUANG <[email-masked]>
Date: Tue, 08 Jun 2010 16:44:57 +0800

Hi Shree,

Thank you very much for your reply.

I checked with RFC 4861 just now. You are right that there is no field to
carry the service information associated with the prefix in the Prefix
Information Option.

I don't have any preference to use RA over DHCPv6, but I would be grateful
if you could tell me the guidance to decide whether to deploy SLAAC or
DHCPv6.
Obviously, SLAAC can not work as expected in the scenario in my example. So
this seems be to a restriction to the deployment of SLAAC at least for the
time being (any possibility for the SLAAC/RA to support multiple prefix
pools for different services in the future?). 

Best regards,
Fortune

-----Original Message-----
From: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
[mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 12:57 PM
To: Fortune HUANG; [email-masked]
Subject: RE: Question about SLAAC: how the host determines the prefixes
allocated from different prefix pools

Fortune,

As per RFC 4862 "section 5.5.3. Router Advertisement Processing  of RFC" 
STB should generate two global addresses.
Please note  Prefix Information Option in Router Advertisement does not
contain a way to associate a prefix with a service.
DHCPv6 will be a better option to request an IPv6 address/prefix for a
particular service.

--
Shree

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fortune HUANG
Sent: Tuesday, June 08, 2010 8:00 AM
To: [email-masked]
Subject: Question about SLAAC: how the host determines the prefixes
allocated from different prefix pools

Dear all,

 
For example, suppose we have two prefix pools, one for the IPTV service and
the other for the HSI service.
For a specific link with a PC for the HSI service and a STB for the IPTV
service,  the router generates the Router Advertisements with two
active prefixes allocated from the two different pools. 
1) Will the STB accept both prefixes and generate two global addresses?
1) Or the STB will accept only the prefix allocated from the prefix pool for
IPTV? 

Best regards,
Fortune

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Jun 2010 09:52:57 +0100

> pools for different services in the future?). 

In principle if each prefix is used with a service that is served from that prefix, then if the device implements RFC3484 address selection your multi-addressed hosts should use the correct source addresses.    The device would prefer the longest matching prefix.    It's also possible to use policy tables with address selection to influence address selection decisions.

Note though that RFC3484 has some open issues that are hopefully to be resolved with an update soon (many implementors have already reflected these updates in their products) but also that at least one major operating system (Mac OSX) as yet has no support for the feature.   A method to distribute policy tables (by DHCPv6) is also on the table.

Tim

---

From: Fortune HUANG <[email-masked]>
Date: Tue, 08 Jun 2010 17:30:25 +0800

Hi Tim,

I don't know much about RFC3484, but do you mean that the STB in my example
can choose the expected prefix/address via the Policy Table?
What is in the Policy Table and how to configure it? Manually (maybe not
acceptable for SLAAC case) or automatically?

Thanks!

Best regards,
Fortune

-----Original Message-----
From: Tim Chown [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 4:53 PM
To: Fortune HUANG
Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; [email-masked]
Subject: Re: Question about SLAAC: how the host determines the prefixes

On 8 Jun 2010, at 09:44, Fortune HUANG wrote:

> 
> I don't have any preference to use RA over DHCPv6, but I would be 
> grateful if you could tell me the guidance to decide whether to deploy 
> SLAAC or DHCPv6.
> Obviously, SLAAC can not work as expected in the scenario in my 
> example. So this seems be to a restriction to the deployment of SLAAC 
> at least for the time being (any possibility for the SLAAC/RA to 
> support multiple prefix pools for different services in the future?).
> 

In principle if each prefix is used with a service that is served from that
prefix, then if the device implements RFC3484 address selection your
multi-addressed hosts should use the correct source addresses.    The device
would prefer the longest matching prefix.    It's also possible to use
policy tables with address selection to influence address selection
decisions.

Note though that RFC3484 has some open issues that are hopefully to be
resolved with an update soon (many implementors have already reflected these
updates in their products) but also that at least one major operating system
(Mac OSX) as yet has no support for the feature.   A method to distribute
policy tables (by DHCPv6) is also on the table.

Tim=

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Jun 2010 15:33:33 +0100

So if you look at section 10 of RFC3484 you'll see some examples of how the policy table can be used.   Where the table is stored will be implementation specific, but the behaviour should be consistent.   You may (or may not) find the default rules achieve what you need.

At the moment there's no way to distribute the policy table within a site, which is why there's been some analysis of this (see draft-ietf-6man-addr-select-considerations-00) and a DHCPv6-based solution proposed (see draft-fujisaki-dhc-addr-select-opt-09).    Until such a mechanism is available, you need to manually edit the table or include the correct/desired table in whatever system/method you use to distribute configurations to managed devices in a site.

Tim

---

From: Fortune HUANG <[email-masked]>
Date: Wed, 09 Jun 2010 17:22:43 +0800

Hi Tim and Shree,

I am not sure if the policy table is applicable for selection of the
prefixes allocated from different prefix pools for different service types,
because the service type is a kind of property of each prefix, while "the
Policy Table is a longest-matching-prefix lookup table, much like a routing
table"(see in RFC 3484). 

In DHCPv6, the problem seems to be solved by the User Class Option. The User
Class option "is used by a DHCP client to optionally identify the type
   or category of user or applications it represents. " (see in RFC3004).

So, a potential solution for RA is to carry the User Class in the RA
message. Maybe we can consider to extend the Prefix Information Option to
include the corresponding user class(e.g. service type) or define a new
option for the binding of the prefix and its user class. What do you think?

Best regards,
Fortune

-----Original Message-----
From: Tim Chown [mailto:[email-masked]] 
Sent: Tuesday, June 08, 2010 10:34 PM
To: Fortune HUANG
Cc: 'JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)'; [email-masked]
Subject: Re: Question about SLAAC: how the host determines the prefixes

So if you look at section 10 of RFC3484 you'll see some examples of how the
policy table can be used.   Where the table is stored will be implementation
specific, but the behaviour should be consistent.   You may (or may not)
find the default rules achieve what you need.

At the moment there's no way to distribute the policy table within a site,
which is why there's been some analysis of this (see
draft-ietf-6man-addr-select-considerations-00) and a DHCPv6-based solution
proposed (see draft-fujisaki-dhc-addr-select-opt-09).    Until such a
mechanism is available, you need to manually edit the table or include the
correct/desired table in whatever system/method you use to distribute
configurations to managed devices in a site.

Tim
 
On 8 Jun 2010, at 10:30, Fortune HUANG wrote:

> Hi Tim,
> 
> I don't know much about RFC3484, but do you mean that the STB in my 
> example can choose the expected prefix/address via the Policy Table?
> What is in the Policy Table and how to configure it? Manually (maybe 
> not acceptable for SLAAC case) or automatically?
> 
> Thanks!
> 
> Best regards,
> Fortune
> 
> 
> Subject: Re: Question about SLAAC: how the host determines the 
> prefixes allocated from different prefix pools
> 
> 
>> grateful if you could tell me the guidance to decide whether to 
>> deploy SLAAC or DHCPv6.
> In principle if each prefix is used with a service that is served from 
> that prefix, then if the device implements RFC3484 address selection your
> resolved with an update soon (many implementors have already reflected 
> these updates in their products) but also that at least one major
operating system

---

From: Brian Haberman <[email-masked]>
Date: Wed, 09 Jun 2010 07:45:06 -0400

Speaking only as a WG member...

> option for the binding of the prefix and its user class. What do you think?

I believe this type of functionality belongs in DHCPv6 and not in an RA
option (or extension to the PIO).  The complexity the User Class Option
allows is better managed in a centralized approach like DHCPv6.  It
conflicts greatly with the original intent of simplicity of SLAAC.

Regards,
Brian

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

---

From: Fortune HUANG <[email-masked]>
Date: Wed, 09 Jun 2010 21:01:58 +0800

Hi Brian,

Thank you very much for your comments. 

With your comments, I realize that the User Class Option defined in RFC 3004
allows much flexibility because the User Class value is an opaque field and
implementation specific. Without a centralized control point, the value of
the User Class can not be well maintained. So I agree with you that the User
Class Option is better managed in the centralized approach like DHCPv6 and
the User Class can not be introduced to RA in the same way as defined in RFC
3004.

So I think if we would like to extend the RA or PIO option, we would need
unified or global values for the service types (not using the User Class in
this case). That is to say, the service types associated with the prefix
should be allocated by IANA. What do you think? Would this approach be
better?

Thanks again!

Best regards,
Fortune

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Wednesday, June 09, 2010 7:45 PM
To: [email-masked]
Subject: Re: Question about SLAAC: how the host determines the
prefixesallocated from different prefix pools

Regards,
Brian

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Wed, 9 Jun 2010 19:23:53 +0530

Hi Fortune,

Why extend RA to achieve something that's already available through DHCPv6 (a proven operational model) ?

--
Shree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fortune HUANG
Sent: Wednesday, June 09, 2010 6:32 PM
To: 'Brian Haberman'; [email-masked]
Subject: RE: Question about SLAAC: how the host determines the prefixesallocated from different prefix pools

Hi Brian,

Thanks again!

Best regards,
Fortune

---

From: Brian Haberman <[email-masked]>
Date: Wed, 09 Jun 2010 11:12:52 -0400

> should be allocated by IANA. What do you think? Would this approach be

The management of that registry would be chaotic.  There is good reason
why the User Class value is opaque.  Each network has its own set of
requirements and the aggregated requirements would overwhelm the registry.

In this type of scenario, I would prefer to have networks needing this
type of functionality to stick with the proven technology.

Regards,
Brian

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 11 Jun 2010 09:00:17 +0800

Hi Shree,

Sorry for the late reply because I was on a bussiness trip yesterday.

The reason I propose to extend RA is because that DHCPv6 may not be
available in some scenario.
If the extension is simple enough, it may be worthy.

Best regards,
Fortune

-----Original Message-----
From: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
[mailto:[email-masked]] 
Sent: Wednesday, June 09, 2010 9:54 PM
To: Fortune HUANG; 'Brian Haberman'; [email-masked]
Subject: RE: Question about SLAAC: how the host determines the
prefixesallocated from different prefix pools

Hi Fortune,

Why extend RA to achieve something that's already available through DHCPv6
(a proven operational model) ?

--
Shree

-----Original Message-----
Subject: RE: Question about SLAAC: how the host determines the

Hi Brian,

Thanks again!

Best regards,
Fortune

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 11 Jun 2010 09:23:52 +0800

Hi Brian,

It seems that we have two options here:
1) Assuming DHCPv6 is always available in the scenario where there are
multiple prefix pools for different services, just use DHCPv6 as you and
Shree said.
2) Assuming DHCPv6 may not be available in some scenario where there are
multiple prefix pools for different services, extend the RA in some way. 

{Brian: "The management of that registry would be chaotic.  There is good
reason why the User Class value is opaque.  Each network has its own set of
requirements and the aggregated requirements would overwhelm the registry."}

Your comment quoted above make sense to me. But I am not confident with the
assumption that DHCPv6 is always available in the scenario where there are
multiple prefix pools for different services, so I will still try to take
some more time to figure out how to extend the RA without such problems. I
would also appreciate it if someone could propose a feasible approach about
this and feed back to mailing list or to me.

Best regards,
Fortune

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Wednesday, June 09, 2010 11:13 PM
To: [email-masked]
Subject: Re: Question about SLAAC: how the host determines
theprefixesallocated from different prefix pools

On 6/9/10 9:01 AM, Fortune HUANG wrote:
> With your comments, I realize that the User Class Option defined in 
> RFC 3004 allows much flexibility because the User Class value is an 
> opaque field and implementation specific. Without a centralized 
> control point, the value of the User Class can not be well maintained. 
> So I agree with you that the User Class Option is better managed in 
> the centralized approach like DHCPv6 and the User Class can not be 
> introduced to RA in the same way as defined in RFC 3004.
> 
> So I think if we would like to extend the RA or PIO option, we would 
> need unified or global values for the service types (not using the 
> User Class in this case). That is to say, the service types associated 
> with the prefix should be allocated by IANA. What do you think? Would 
> this approach be better?

The management of that registry would be chaotic.  There is good reason why
the User Class value is opaque.  Each network has its own set of
requirements and the aggregated requirements would overwhelm the registry.

In this type of scenario, I would prefer to have networks needing this type
of functionality to stick with the proven technology.

Regards,
Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Brian Haberman
>> because the service type is a kind of property of each prefix, while 
>> "the Policy Table is a longest-matching-prefix lookup table, much 
>> like a
> routing
>> table"(see in RFC 3484). 
>>
>> In DHCPv6, the problem seems to be solved by the User Class Option. 
>> The
> User
>> message. Maybe we can consider to extend the Prefix Information 
>> Option to include the corresponding user class(e.g. service type) or 
>> define a new option for the binding of the prefix and its user class. 
>> What do you
> think?
>>
> 
> I believe this type of functionality belongs in DHCPv6 and not in an 
> RA option (or extension to the PIO).  The complexity the User Class 
> Option allows is better managed in a centralized approach like DHCPv6.  
> It conflicts greatly with the original intent of simplicity of SLAAC.
> 
> Regards,
> Brian
> 
>>
>> Best regards,
>> Fortune
>>
>>  
>>
>> So if you look at section 10 of RFC3484 you'll see some examples of 
>> how
> the
>> At the moment there's no way to distribute the policy table within a 
>> site, which is why there's been some analysis of this (see
>> mechanism is available, you need to manually edit the table or 
>> include the correct/desired table in whatever system/method you use 
>> to distribute configurations to managed devices in a site.
>>
>> Tim
>>  
>>>> example. So this seems be to a restriction to the deployment of 
>>>> SLAAC at least for the time being (any possibility for the SLAAC/RA 
>>>> to support multiple prefix pools for different services in the
future?).
>>>>
>>>
>>>
>>> In principle if each prefix is used with a service that is served 
>>> from that prefix, then if the device implements RFC3484 address
selection your
>>> Note though that RFC3484 has some open issues that are hopefully to 
>>> be resolved with an update soon (many implementors have already 
>>> reflected these updates in their products) but also that at least 
>>> one major
>> operating system

---

From: Doug Barton <[email-masked]>
Date: Thu, 10 Jun 2010 21:42:06 -0700

> multiple prefix pools for different services, just use DHCPv6 as you and

+1

RA and/or SLAAC are for _simple_ automatic configuration. If your
configuration isn't simple, you need another tool. If the cost of
multiple prefix pools is that deploying them requires DHCP then that is
a cost that the people considering that deployment have to take into
consideration.

As someone else has said already the last time extending RA came up, you
either do every option in both RA and DHCP, or you limit RA to the role
it has now and do more robust host configuration using the protocol
already designed for that purpose. My vote is for the latter option.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 11 Jun 2010 13:09:42 +0800

Hi Brian,

I just have an idea to improve my previous solution. We can have two more
parameter in RA.
1) Network Service Provider(NSP) ID: The value of this field is maintained
by the IANA.
2) Service Type: The value [0, 65535] is maintained by the IANA.   The
values 65536 and above are NSP specific, and should only be used when NSP ID
is present.

The PIO in the RA could be extended as follows:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     | Prefix Length |L|A|N|S| Resv1 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Preferred Lifetime                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved2                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                            Prefix                             +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Network Service Provider(NSP) ID              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Service Type                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      P:  1-bit NSP flag.  When set indicates that NSP ID field is present.
      S:   1-bit service-type flag.  When set indicates that Service Type
field is present.
      NSP ID:  Indicates the NSP.
      Service Type: Indicates the service type. The value [0, 65535] is
maintained by the IANA. 
                    The values 65536 and above are NSP specific, and should
only be used when NSP ID field is present.
 
What do you think of this approach? 

Best regards,
Fortune 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fortune HUANG
Sent: Friday, June 11, 2010 9:24 AM
To: 'Brian Haberman'; [email-masked]
Subject: RE: Question about SLAAC: how the host determines
theprefixesallocatedfrom different prefix pools

Hi Brian,

Best regards,
Fortune

-----Original Message-----

Regards,
Brian

future?).
selection your

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Fri, 11 Jun 2010 11:40:49 +0530

Hi Fortune,

Perhaps TR-177 discussion on broadband forum would be a more appropriate place for this discussion.

If operational model is clear (i.e. which parameters need to be provided through RA) not just service/prefix
but also DNS, SNTP information, VLAN/service etc then a proposal combining all the options in a draft can be made to WG.

--
Shree 

-----Original Message-----
From: Fortune HUANG [mailto:[email-masked]] 
Sent: Friday, June 11, 2010 6:30 AM
To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK); 'Brian Haberman'; [email-masked]
Subject: RE: Question about SLAAC: how the host determines the prefixesallocated from different prefix pools

Hi Shree,

Best regards,
Fortune

-----Original Message-----

Hi Fortune,

--
Shree

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 11 Jun 2010 16:04:06 +0800

Hi Shree,

Thanks for the information.

I will be looking forward to the single draft with all the extensions to RA,
but I don't mind writing an individual draft to mark this bullet first if it
makes sense.

Best regards,
Fortune

-----Original Message-----
Sent: Friday, June 11, 2010 2:11 PM

Hi Fortune,

Perhaps TR-177 discussion on broadband forum would be a more appropriate
place for this discussion.

If operational model is clear (i.e. which parameters need to be provided
through RA) not just service/prefix but also DNS, SNTP information,
VLAN/service etc then a proposal combining all the options in a draft can be
made to WG.

--
Shree 

-----Original Message-----
From: Fortune HUANG [mailto:[email-masked]]
Sent: Friday, June 11, 2010 6:30 AM
To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK); 'Brian Haberman';
[email-masked]

Hi Shree,

Best regards,
Fortune

-----Original Message-----

Hi Fortune,

--
Shree

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 11 Jun 2010 16:51:25 +0800

Hi Doug,

Prompted by your comment, I realize that there is a major difference between
the the service type and some other options from DHCP.
We actually have two categories of information for the host: 1)
Address/Prefix and its properties  (e.g. valid period of the prefix, service
type of the prefix) ; 2) other information without a close association with
the Address/Prefix.

Suppose the host gets all the configuration via both RA and stateless
DHCPv6.  The first category should be obtained via RA, while the second
category should be obtained via stateless DHCPv6 such as the addresses of
DNS recursive name servers (see in RFC3736).

So I think it would be reasonable to treat the two categories differently.

Best regards,
Fortune

-----Original Message-----
From: Doug Barton [mailto:[email-masked]] 
Sent: Friday, June 11, 2010 12:42 PM
To: Fortune HUANG
Cc: 'Brian Haberman'; [email-masked]
Subject: Re: Question about SLAAC: how the host determines

On 6/10/2010 6:23 PM, Fortune HUANG wrote:
> multiple prefix pools for different services, just use DHCPv6 as you 
> and Shree said.

+1

RA and/or SLAAC are for _simple_ automatic configuration. If your
configuration isn't simple, you need another tool. If the cost of multiple
prefix pools is that deploying them requires DHCP then that is a cost that
the people considering that deployment have to take into consideration.

As someone else has said already the last time extending RA came up, you
either do every option in both RA and DHCP, or you limit RA to the role it
has now and do more robust host configuration using the protocol already
designed for that purpose. My vote is for the latter option.

Doug

--

---

From: Mark Smith <[email-masked]>
Date: Fri, 11 Jun 2010 18:26:49 +0930

On Fri, 11 Jun 2010 11:40:49 +0530
"JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)"

> but also DNS, SNTP information, VLAN/service etc then a proposal combining all the options in a draft can be made to WG.

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

"Architectural Principles of the Internet"

"3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements."

---

From: Fortune HUANG <[email-masked]>
Date: Sun, 13 Jun 2010 08:31:47 +0800

Hi Mark,

As discussed in my previous emails, this is an improvement to RA. 
1) The service type of the prefix is the property of a prefix, it should be
carried in RA rather than stateless DHCP.
2) The RA approach has the advantage that the server doesn't need to
maintain the states of each host, while the stateful DHCPv6 approach doesn't
have.

So, according to the text you quoted, we should not reject this improvement.

Best regards,
Fortune

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Friday, June 11, 2010 4:57 PM
To: JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)
Cc: Fortune HUANG; 'Brian Haberman'; [email-masked]
Subject: Re: Question about SLAAC: how the host determines the

> 
> If operational model is clear (i.e. which parameters need to be 
> provided through RA) not just service/prefix but also DNS, SNTP
information, VLAN/service etc then a proposal combining all the options in a
draft can be made to WG.

---

From: Mark Smith <[email-masked]>
Date: Sun, 13 Jun 2010 11:25:17 +0930

Hi Fortune,

On Sun, 13 Jun 2010 08:31:47 +0800

> So, according to the text you quoted, we should not reject this improvement.

This was the text I was referring to -

"but also DNS, SNTP information, VLAN/service etc then a proposal
combining all the options in a draft can be made to WG."

I read that as a proposal is going to be made to provide all DHCPv6
options in RAs. Is that the case?

Regards,
Mark.

---

From: Fortune HUANG <[email-masked]>
Date: Sun, 13 Jun 2010 10:31:46 +0800

Hi Mark,

I think it should be read like this:
Some options would be extended from DHCPv6 to RA, and all those extensions
might be in a single draft.

Best regards,
Fortune 

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Sunday, June 13, 2010 9:55 AM
To: Fortune HUANG
Cc: [email-masked]
Subject: Re: Question about SLAAC: how the host determines the

Hi Fortune,

On Sun, 13 Jun 2010 08:31:47 +0800
Fortune HUANG <[email-masked]> wrote:

> 1) The service type of the prefix is the property of a prefix, it 
> should be carried in RA rather than stateless DHCP.
> maintain the states of each host, while the stateful DHCPv6 approach 
> doesn't have.
> 

"but also DNS, SNTP information, VLAN/service etc then a proposal combining
all the options in a draft can be made to WG."

I read that as a proposal is going to be made to provide all DHCPv6 options
in RAs. Is that the case?

Regards,
Mark.

> From: Mark Smith 
> [mailto:[email-masked]]
> information, VLAN/service etc then a proposal combining all the 
> options in a draft can be made to WG.
> > 
> 
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <[email-masked]>
Date: Sun, 13 Jun 2010 12:14:48 +0530

Mark,

>> in RAs. Is that the case?

The intent is to look at the minimal options necessary to support a meanigul deployment using SLACC. 
And not replicate everything that's in dhcpv6 into SLAAC.

--
Shree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fortune HUANG
Sent: Sunday, June 13, 2010 8:02 AM
To: [email-masked]
Subject: RE: Question about SLAAC: how the host determines the prefixesallocated from different prefix pools

Hi Mark,

Best regards,
Fortune

---

From: Mark Smith <[email-masked]>
Date: Mon, 14 Jun 2010 15:46:04 +0930

On Sun, 13 Jun 2010 10:31:46 +0800

> might be in a single draft.

Some or all of the DHCPv6 options doesn't matter - it's duplicating
existing functionality, with no evidence that the existing
functionality doesn't work or is unacceptably inefficient. In all the
recent discussion regarding the supposed "inadequacies" of DHCPv6, the
best people seem to have come up with is "I don't like it". There has
been no "we tried to deploy it, but we had this problem, and we see RA
DHCPv6 options to be the only solution", or, "on our embedded platform
with X KB of RAM, we couldn't fit a stateless DHCPv6 client". In other
words, I think the people who want to add these sorts of options into
RAs are obligated to prove, not just hypothesise, that existing methods
aren't adequate.

I have great concerns that reinventing how end-nodes are
configured, (and that is what putting DHCPv6 options in RAs is), is
only going to further create yet another reason for people to delay
deploying IPv6.

I'm working on a deployment of IPv6 to 100K+ ADSL residential
subscribers. If there is any introduced doubt or confusion at this
point in time as to the methods and machanims will be used to provision
end-nodes, then it is safer for organisations like the one I'm working
with to halt their deployments until there is a clear and single
direction. I don't want to have to be in the position to recommend
stopping deployment, yet I'll have to if I think that organisations I
work with are about to go to a great expense to deploy services and
supporting infrastructure that will be obsolete in only a few years
time.

As a protocol, IPv6 is supposed to ready to be deployed, and I broadly
think it is - all the functions required to provision commercial
residential IPv6 services are specified and code exists. The "rough
consensus and running code" threshold has been met. People may feel the
need to "tweak" it, however I don't think they realise the hidden and
significant costs those "tweaks" will create to existing and near
future deployments, including the possibility of causing those
deployments to stop.

Have a think about the following post, regarding detecting rogue DNS
server addresses or rogue DNS domains in rogue RAs, and then consider
that the same problem will occur with any and all other options that
may be added to RAs. Bear in mind that the devices are intended to do
rouge RA detection are layer 2 devices. Think about how hard it is for
a layer 2 device to inspect a packet type verses inspecting the values
of options (that may or may not be present) for validity. Think about
the question of whether it be acceptable to upgrade the firmware in all
layer 2 devices every time a new RA option is defined, and whether it
is reasonable to have to configure all layer 2 switches with all the
values for RA options so they can inspect them for validity.

http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00756.html

Regards,
Mark.

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 14 Jun 2010 09:11:19 -0400

+1
I completely agree with what Mark said here.
Barbara

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mark Smith
> Sent: Monday, June 14, 2010 2:16 AM
> To: Fortune HUANG
> Cc: [email-masked]
> combining
> > > > Why extend RA to achieve something that's already available
> through
> > > > DHCPv6 (a proven operational model) ?
> > > >
> > > > --
> > > > Shree
> > > >
-----------------------------------------------------------------
> ---
-----------------------------------------------------------------
> ---
-------------------------------------------------------------------
> -
> > > Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------------
> -

---

From: Brian Haberman <[email-masked]>
Date: Mon, 14 Jun 2010 09:53:12 -0400

> 1) Network Service Provider(NSP) ID: The value of this field is maintained

And how does an end-host utilize the NSP ID?

> 2) Service Type: The value [0, 65535] is maintained by the IANA.   The

Does this not force all service providers to use the same Service Type
codes?  My understanding is that these are locally maintained today when
they are used in IPv4.

> The PIO in the RA could be extended as follows:

I still, personally, think that this is too heavyweight for a SLAAC
environment.  It seems more logical to re-use the existing DHCP-based
approach for this level of complex address assignment.

Regards,
Brian

---

From: Fortune HUANG <[email-masked]>
Date: Thu, 17 Jun 2010 08:28:50 +0800

Hi Brian,

Sorry for the delay of the reply because of the 3-day dragon boat festival
in China.

Regarding the definition of Service Type, with the flexibility in my
approach, the service provider can use a commen service type defined by the
IANA and it can also defined its own service types.

Best regards,
Fortune 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brian Haberman
Sent: Monday, June 14, 2010 9:53 PM
To: [email-masked]
Subject: Re: Question about SLAAC: how the host
determinestheprefixesallocatedfrom different prefix pools

On 6/11/10 1:09 AM, Fortune HUANG wrote:
> Hi Brian,
> 
> I just have an idea to improve my previous solution. We can have two 
> more parameter in RA.
> 1) Network Service Provider(NSP) ID: The value of this field is 
> maintained by the IANA.

> values 65536 and above are NSP specific, and should only be used when 
> NSP ID is present.
> 
>       Service Type: Indicates the service type. The value [0, 65535] 
> is maintained by the IANA.
>                     The values 65536 and above are NSP specific, and 
> should only be used when NSP ID field is present.
>  

Regards,
Brian

---

From: Fortune HUANG <[email-masked]>
Date: Thu, 17 Jun 2010 10:02:08 +0800

Hi Mark,

I think DHCPv6 and RA fit in different scenarios. If DHCPv6 without RA is
perfect for some scenario, just use it.
But recently I had some conversations with some network operators, RA is
preferred in some scenario because the DHCP server don't need to maintain
the state of each terminal.

Best regards,
Fortune

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Monday, June 14, 2010 2:16 PM
To: Fortune HUANG
Cc: [email-masked]
Subject: Re: Question about SLAAC: how the host determines the

On Sun, 13 Jun 2010 10:31:46 +0800
Fortune HUANG <[email-masked]> wrote:

> Some options would be extended from DHCPv6 to RA, and all those 
> extensions might be in a single draft.
> 

Some or all of the DHCPv6 options doesn't matter - it's duplicating existing
functionality, with no evidence that the existing functionality doesn't work
or is unacceptably inefficient. In all the recent discussion regarding the
supposed "inadequacies" of DHCPv6, the best people seem to have come up with
is "I don't like it". There has been no "we tried to deploy it, but we had
this problem, and we see RA
DHCPv6 options to be the only solution", or, "on our embedded platform with
X KB of RAM, we couldn't fit a stateless DHCPv6 client". In other words, I
think the people who want to add these sorts of options into RAs are
obligated to prove, not just hypothesise, that existing methods aren't
adequate.

I have great concerns that reinventing how end-nodes are configured, (and
that is what putting DHCPv6 options in RAs is), is only going to further
create yet another reason for people to delay deploying IPv6.

I'm working on a deployment of IPv6 to 100K+ ADSL residential subscribers.
If there is any introduced doubt or confusion at this point in time as to
the methods and machanims will be used to provision end-nodes, then it is
safer for organisations like the one I'm working with to halt their
deployments until there is a clear and single direction. I don't want to
have to be in the position to recommend stopping deployment, yet I'll have
to if I think that organisations I work with are about to go to a great
expense to deploy services and supporting infrastructure that will be
obsolete in only a few years time.

As a protocol, IPv6 is supposed to ready to be deployed, and I broadly think
it is - all the functions required to provision commercial residential IPv6
services are specified and code exists. The "rough consensus and running
code" threshold has been met. People may feel the need to "tweak" it,
however I don't think they realise the hidden and significant costs those
"tweaks" will create to existing and near future deployments, including the
possibility of causing those deployments to stop.

Have a think about the following post, regarding detecting rogue DNS server
addresses or rogue DNS domains in rogue RAs, and then consider that the same
problem will occur with any and all other options that may be added to RAs.
Bear in mind that the devices are intended to do rouge RA detection are
layer 2 devices. Think about how hard it is for a layer 2 device to inspect
a packet type verses inspecting the values of options (that may or may not
be present) for validity. Think about the question of whether it be
acceptable to upgrade the firmware in all layer 2 devices every time a new
RA option is defined, and whether it is reasonable to have to configure all
layer 2 switches with all the values for RA options so they can inspect them
for validity.

Regards,
Mark.

> > > The reason I propose to extend RA is because that DHCPv6 may not 
> > > be available in some scenario.
> > > ------------------------------------------------------------------
> > > -- IETF IPv6 working group mailing list [email-masked] 
> > > Administrative

---

From: Mark Smith <[email-masked]>
Date: Thu, 17 Jun 2010 18:58:27 +0930

Hi Fortune,

On Thu, 17 Jun 2010 10:02:08 +0800

> perfect for some scenario, just use it.

You cannot use DHCPv6 only - RAs are essential for announcing
one or more routers availability onto a link.

> the state of each terminal.

RAs + Stateless DHCPv6 is completely stateless. 

IPv6 has both stateless and stateful end-node configuration methods. It
is unfortunate that that is the case, rather than just one single
method - either stateless or stateful. The reason is that some
users of IPv6 want "database" driven address assignment and
configuration i.e. stateful IPv6, while others want lower resource
stateless. That is unfortunate complexity that we already are going to
have to wear the cost of.

By making RAs do what stateless DHCPv6 already does is further
complexity that fundamentally doesn't achieve anything new - other
than creating more things that can break, and more points of failure. In
fact it does less - there are no proposed methods for how
router per-interface RA option configuration updating can be
centralised, yet they already exist for DHCPv6 (by having router
interfaces act as DHCPv6 relays). So after people work out RA options,
they'll then think about how to scale distributing the configuration for
them ... and then they'll have completely re-invented stateless DHCPv6.
The fundamental result will be two near equal methods of achieving the
same thing, and twice as many possibilities for misconfiguration,
arbitration between conflicting options supplied by the alternative
methods and code bugs.

As I said before, it all sounds like "I don't like it" or
maybe in your operator case, "I don't fully understand how IPv6 works"
reasoning. It seems to me that the challenge of providing hard
evidence of failures or inadequacies of existing methods still stands.

Regards,
Mark.

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 18 Jun 2010 08:39:39 +0800

Hi Mark,

{Mark: You cannot use DHCPv6 only - RAs are essential for announcing one or
more routers availability onto a link.}
Right. What I meant was you can use DHCPv6 without RA to allocate the prefix
for some scenarios if you think it is perfect.

As I said before, we are not going to re-invent the stateless DHCPv6, but
only an improvement to RA.
1) For the stateful case, we should use DHCPv6.
2) For the stateless case, we prefer to use RA plus stateless DHCPv6. In my
opinion, RA should be used for prefix related configuration, stateless
DHCPv6 should be used for other configuration. Since the service type of the
prefix should be classified to the prefix related configuration, it should
be carried in RA, otherwise it would be difficult to correlate the prefix
and the corresponding service type. But for other configuration without
binding with the prefixes of the host, that's a different case which I don't
want to cover in this thread.

Best regards,
Fortune

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Thursday, June 17, 2010 5:28 PM
To: Fortune HUANG
Cc: [email-masked]
Subject: Re: Question about SLAAC: how the host determines the

Hi Fortune,

On Thu, 17 Jun 2010 10:02:08 +0800
Fortune HUANG <[email-masked]> wrote:

> Hi Mark,
> 
> I think DHCPv6 and RA fit in different scenarios. If DHCPv6 without RA 
> is perfect for some scenario, just use it.

You cannot use DHCPv6 only - RAs are essential for announcing one or more
routers availability onto a link.

> But recently I had some conversations with some network operators, RA 
> is preferred in some scenario because the DHCP server don't need to 
> maintain the state of each terminal.
> 

IPv6 has both stateless and stateful end-node configuration methods. It is
unfortunate that that is the case, rather than just one single method -
either stateless or stateful. The reason is that some users of IPv6 want
"database" driven address assignment and configuration i.e. stateful IPv6,
while others want lower resource stateless. That is unfortunate complexity
that we already are going to have to wear the cost of.

By making RAs do what stateless DHCPv6 already does is further complexity
that fundamentally doesn't achieve anything new - other than creating more
things that can break, and more points of failure. In fact it does less -
there are no proposed methods for how router per-interface RA option
configuration updating can be centralised, yet they already exist for DHCPv6
(by having router interfaces act as DHCPv6 relays). So after people work out
RA options, they'll then think about how to scale distributing the
configuration for them ... and then they'll have completely re-invented
stateless DHCPv6.
The fundamental result will be two near equal methods of achieving the same
thing, and twice as many possibilities for misconfiguration, arbitration
between conflicting options supplied by the alternative methods and code
bugs.

As I said before, it all sounds like "I don't like it" or maybe in your
operator case, "I don't fully understand how IPv6 works"
reasoning. It seems to me that the challenge of providing hard evidence of
failures or inadequacies of existing methods still stands.

Regards,
Mark.

> RAs are obligated to prove, not just hypothesise, that existing 
> methods aren't adequate.
> 
> I have great concerns that reinventing how end-nodes are configured, 
> (and that is what putting DHCPv6 options in RAs is), is only going to 
> further create yet another reason for people to delay deploying IPv6.
> 
> If there is any introduced doubt or confusion at this point in time as 
> to the methods and machanims will be used to provision end-nodes, then 
> it is safer for organisations like the one I'm working with to halt 
> their deployments until there is a clear and single direction. I don't 
> want to have to be in the position to recommend stopping deployment, 
> yet I'll have to if I think that organisations I work with are about 
> to go to a great expense to deploy services and supporting 
> infrastructure that will be obsolete in only a few years time.
> 
> consensus and running code" threshold has been met. People may feel 
> the need to "tweak" it, however I don't think they realise the hidden 
> and significant costs those "tweaks" will create to existing and near 
> future deployments, including the possibility of causing those deployments
to stop.
> that the same problem will occur with any and all other options that may
be added to RAs.
> Bear in mind that the devices are intended to do rouge RA detection 
> are layer 2 devices. Think about how hard it is for a layer 2 device 
> to inspect a packet type verses inspecting the values of options (that 
> may or may not be present) for validity. Think about the question of 
> whether it be acceptable to upgrade the firmware in all layer 2 
> devices every time a new RA option is defined, and whether it is 
> reasonable to have to configure all layer 2 switches with all the 
> > > 2) The RA approach has the advantage that the server doesn't need 
> > > to maintain the states of each host, while the stateful DHCPv6 
> > > approach doesn't have.
> > > 
> > > On Fri, 11 Jun 2010 11:40:49 +0530 "JOSHI, SHRINIVAS ASHOK 
> > > (SHRINIVAS ASHOK)"

---

From: Doug Barton <[email-masked]>
Date: Thu, 17 Jun 2010 18:42:15 -0700

On 06/17/10 17:39, Fortune HUANG wrote:
> Since the service type of the prefix should be classified to the
> prefix related configuration, it should be carried in RA

... and what Mark, myself, and everyone else who have +1'ed our
statements is saying is that "Fortune HUANG wants it to be that way" is 
not a valid reason for the working group to take up the project. I'm 
sorry to be so blunt, but we've gone round on this a few times now and 
the message does not seem to be sinking in. :) Given that you can 
already handle the case of multiple prefixes with DHCP that is how this 
problem should be solved.

If you would like to demonstrate that the DHCP solution for this problem 
is deficient in some way, that is a whole different topic, and you 
should start a new thread with your demonstration of how and why it is 
deficient. Please be sure to document your testing methodology so that 
we can review it and attempt to reproduce the results ourselves.

Doug

--

---

From: Fortune HUANG <[email-masked]>
Date: Fri, 18 Jun 2010 10:31:03 +0800

Hi Doug,

Please note that "Fortune HUANG wants it to be that way" has never been used
as any kind of reason in this discussion by myself.  

I also assume you are not using that "Doug doesn't want it to be that way"
as a valid reason not to take up the project, so please respond to my reason
as you quoted below if you like. Do you think that the service type of the
prefix should be classified to the prefix related configuration or not? If
yes, do you agree that it should be carried in RA in the stateless case? 

Best regards,
Fortune

-----Original Message-----
From: Doug Barton [mailto:[email-masked]] 
Sent: Friday, June 18, 2010 9:42 AM
To: Fortune HUANG
Cc: [email-masked]
Subject: Re: Question about SLAAC: how the host determines the prefixes

> prefix related configuration, it should be carried in RA

... and what Mark, myself, and everyone else who have +1'ed our statements
is saying is that "Fortune HUANG wants it to be that way" is not a valid
reason for the working group to take up the project. I'm sorry to be so
blunt, but we've gone round on this a few times now and the message does not
seem to be sinking in. :) Given that you can already handle the case of
multiple prefixes with DHCP that is how this problem should be solved.

If you would like to demonstrate that the DHCP solution for this problem is
deficient in some way, that is a whole different topic, and you should start
a new thread with your demonstration of how and why it is deficient. Please
be sure to document your testing methodology so that we can review it and
attempt to reproduce the results ourselves.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Thu, 17 Jun 2010 19:37:14 -0700

On 06/17/10 19:31, Fortune HUANG wrote:
> Hi Doug,
>
> Please note that "Fortune HUANG wants it to be that way" has never
> been used as any kind of reason in this discussion by myself.

Actually that's the only justification you've provided so far.

> so please respond to my reason as you quoted below if you like. Do
> you think that the service type of the prefix should be classified to
> the prefix related configuration or not?

Short answer, no. Longer answer, Mike has already said more eloquently 
than I why that is the answer. Longer longer answer, the ball is in your 
court to demonstrate why the existing DHCP solution is inadequate.

Doug

--

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 18 Jun 2010 10:24:36 -0400

Hi Fortune,
   I have to agree with Brian, Mark and Doug here. SLAAC was conceived 
for use in simple scenarios. The scenario you are describing is a bit 
more complex. I think it calls for DHCPv6.

On a purely technical note, since the prefixes come from different pools 
it is no longer possible to multicast RAs, and this takes away the 
biggest advantage of using RAs. Hence any efficiency claim of using RAs 
is completely lost. A DHCPv6 exchange will be equally if not more efficient.

Thanks
Suresh

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 18 Jun 2010 10:49:15 -0400

> Do you think that the service type of
> the prefix should be classified to the prefix related configuration or
not?
> If yes, do you agree that it should be carried in RA in the stateless
> case?

Nobody is disagreeing that *if* we could turn the clock back 10 years or
so and have a greenfield discussion about creating brand new IPv6
standards that this might be something to consider.

So, just to get past your question, let's say, for the sake of argument,
that we all agree 100% that it would be more logical (a prettier way of
doing things) to do all prefix-related configuration in RA. OK.

Here is what we are saying:
That is irrelevant. It is irrelevant that this would be a prettier way
of doing things. Solutions exist. They have been coded and are being
implemented. Hurdles for starting new standards work to change things
that are already out in the field and being used are different than the
hurdles for starting new standards where nothing exists.

The hurdle when doing greenfield standards is indeed to convince others
that what you propose is the most logical and efficient way of doing
things. The hurdle when trying to convince others to go to the pain,
effort, expense, suffering, and uncertainty of changing existing
implementations and deployments, is to prove that the existing
mechanisms are somehow insufficient or broken.

So, to summarize...
If you want to convince people to move forward with this proposal, you
need to stop trying to convince us that your solution is more logical
and inefficient. That's irrelevant, and we don't care. You need to
convince us that what we have is insufficient or broken.
Barbara

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 Jun 2010 09:32:35 -0700 (PDT)

Hi Suresh,
  I think multicast advantage of RAs is lost in case of point to point links anyways.

Regards,

Behcet

----- Original Message ----
> From: Suresh Krishnan <[email-masked]>
> To: Fortune HUANG <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Fri, June 18, 2010 9:24:36 AM
> Subject: Re: Question about SLAAC: how the host determines the prefixes allocated from different prefix pools
> 
> Hi Fortune,
  I have to agree with Brian, Mark and Doug here. SLAAC was 
> conceived for use in simple scenarios. The scenario you are describing is a bit 

On a purely technical note, 
> since the prefixes come from different pools it is no longer possible to 
> multicast RAs, and this takes away the biggest advantage of using RAs. Hence any 
> efficiency claim of using RAs is completely lost. A DHCPv6 exchange will be 
> equally if not more efficient.

Thanks
Suresh

On 10-06-17 10:31 
> PM, Fortune HUANG wrote:
> Hi Doug,
> 
> Please note that 
> "Fortune HUANG wants it to be that way" has never been used
> as any kind 
> I also assume you are not 
> using that "Doug doesn't want it to be that way"
> as a valid reason not 
> to take up the project, so please respond to my reason
> as you quoted 
> below if you like. Do you think that the service type of the
> prefix 
> should be classified to the prefix related configuration or not? If
> yes, 
> do you agree that it should be carried in RA in the stateless case? 
> 
> 
> Best regards,
> Fortune
> 
> 
> -----Original 
> Message-----
> From: Doug Barton [mailto:> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]] Sent: Friday, June 
> 18, 2010 9:42 AM
> To: Fortune HUANG
> Cc: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]
> Subject: Re: Question 
> about SLAAC: how the host determines the prefixes
> allocated from 
> different prefix pools
> 
>> Since the service type of the prefix should be classified to 
> the prefix related configuration, it should be carried in RA
> 
> 
> statements
> deficient in some way, that is a 
> whole different topic, and you should start
> a new thread with your 
> demonstration of how and why it is deficient. Please
> be sure to document 
> your testing methodology so that we can review it and
> attempt to 

IETF 
> IPv6 working group mailing list
> href="mailto:[email-masked]">[email-masked]
Administrative Requests: > href="https://www.ietf.org/mailman/listinfo/ipv6" target=_blank

---

From: Fortune HUANG <[email-masked]>
Date: Sat, 19 Jun 2010 14:00:25 +0800

Hi Barbara,

Thank you very much for your comment. I am glad to see that you agree with
that it would be more logical to do all prefix-related configuration in RA.
But yes, you are right that we need to prove what we have is insufficient or
broken before we change the existing implementation. I once thought this was
so obvious but it seems not. So I may need to spend some more time on this
before I can get back on this topic. 

Anyway, thanks to everyone that participated in this thread for the valuable
comments. The original intent of this thread is to solve a puzzle about
multiple prefix pools for different services. We finally came up with a
well-recognized DHCPv6 approach and a potential but pending RA approach for
the time being. So I am quite satisfied with this outcome for the time being
and I really appreciate the active and quick responses on this thread.
Thanks again!

Best regards,
Fortune

-----Original Message-----
From: STARK, BARBARA H (ATTLABS) [mailto:[email-masked]] 
Sent: Friday, June 18, 2010 10:49 PM
To: Fortune HUANG
Cc: [email-masked]
Subject: RE: Question about SLAAC: how the host determines the

not?

So, to summarize...