RE: RFC7084

The thing to understand is that, imho:

M=1 should not be equal to force request ia_na.  And yes, our CPEs can do this perfectly, but no, this should not be enforced.  I'm just trying to stick as close as possible to standards, after all, what's the purpose of having separate options (ia_na and ia_pd)  if you're going to request both of them anyway ?

Regs
Carl

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: dinsdag 10 december 2013 15:22
To: ipv6@ietf.org
Subject: Re: RFC7084

Le 2013-12-10 02:13, Wuyts Carl a écrit :
>> Again, you're binding WRONG the M to ia_na.  this is really not good.
>> Let us implement standards based upon what they are designed for.  
>> The M-flag was initially designed to flag the device to be Managed, 
>> not to
>
>  From RFC4861:
>
> M              1-bit "Managed address configuration" flag.  When
>                        set, it indicates that addresses are available via
>                        Dynamic Host Configuration Protocol [DHCPv6].
>
> I interpret this as M=1 means addresses are available via DHCPv6, that means IA_NA and/or IA_PD, one or both might be available. I don't really understand why you do not. What do you think the M flag means? Reading the above text seems to indicate that you think it has something to do with managing the CPE?
>
> [Carl] Correct, as you state and/OR, not AND only.  RFC7084 today says AND.

Am I the only one not understanding Carl's point? I would really like to understand...

> [Carl] why ask for both ?  Why making diff between the 2 if you always ask for both ?  Why not asking all options and just wait and see what you get back ?

As others previously explained, you're free to implement it that way if you prefer: do SLAAC and DHCPv6 simultaneously, and see what you get back.

If I was implementing a CPE, that's what I would do. I would completely ignore the M bit, and the SLAAC and DHCPv6 processes would be like ships in the night.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------