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.

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.

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

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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to