RE: RFC7084

["STARK, BARBARA H" <[e-mail]>]

RFC7084-compliant CE routers are defined to work in an environment where the access network makes the rules. RFC7084-compliant CE routers, by definition of the scope of that RFC, must be able to operate in the access networks defined by CableLabs and BBF, at the very least. These CE routers don't get to make the rules. The supported-for-interoperability access networks include ones that require IA_NA for proper operation. They also include ones that do "unnumbered" model and use only IA_PD. They even include access networks that support SLAAC + IA_PD (with no IA_NA). An RFC7084-compliant CE router will automatically work in all of these access networks, with no special configuration. This was a core goal of the requirements in RFC7084.

If an access network is designed to require CE routers to acquire IA_NA, then that CE router needs to acquire the IA_NA in order to function on that access network. This is not negotiable, and is not something the CE router can "choose" not to do because it doesn't feel like it. It was agreed that an access network that expects IA_NA to be requested will signal this by always setting M=1 in its RA messages. If the access network does not set M=1, it cannot be sure the CE router will request IA_NA. If it does set M=1, it *can* be sure the RFC7084-compliant CE router will request IA_NA.

What was agreed, was that CE routers MUST request IA_NA if M=1 in the RA. You are completely correct in your reading of the requirement. If the access network is designed so that IA_PD is enough, then it will not supply IA_NA in response to the CE router's request. Such access networks have no difficulty in not providing IA_NA.  If the access network is designed to require IA_NA, then it will supply the IA_NA in its response. Since nothing prevents the CE router from always requesting IA_NA, anyway, the access network has to be resilient in the presence of such requests. The CE router is able to work properly in both types of access networks.

There is nothing in the description of the "M" bit in RFC 4861 that would forbid designing an IPv6 host to always request IA_NA whenever it sees M=1. Therefore, this does not go against RFC 4861.
Barbara


From: ipv6 [mailto:[e-mail]] On Behalf Of Wuyts Carl
Sent: Monday, December 09, 2013 9:02 AM
To: <[e-mail]>
Subject: RFC7084

All,

Not sure I should sent this one to DHCPv6 WG or the global IETF v6, so feel free to forward it if needed.

Last week, RFC7084 got posted.  I did already post a message on a rather badly phrased req (a SHOULD one regarding "long-enough", but bumped into the next one today (this one being a lot worse!!).

""
WAA-6:   If the IPv6 CE router receives a Router Advertisement
            message (described in [RFC4861]) with the M flag set to 1,
            the IPv6 CE router MUST do DHCPv6 address assignment
            (request an IA_NA option).
""
I'm not sure who came up with this one, but this is really a no-go.
So, according to this req, the DHCPv6 client must request an ia_na option if an M=1 is being received on his link ???  I might have understood it all wrong, but as far as I know, M=1 is not linked directly to ia_na, ia_pd is enough on its own, no ??  So, the CPE is expected to change its DHCPv6 client configuration based upon receiving an RA with this M=1 content ?
Extract from RFC4861:
""
M              1-bit "Managed address configuration" flag.  When
                     set, it indicates that addresses are available via
                     Dynamic Host Configuration Protocol

""


I'm very curious on the replies now, but this seems really be going the wrong way.  You can launch a CPE which either listen to RA or not, and bound accordingly, however, listen + bind + force ia_na looks a bit too much to me.

regs
Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION

[e-mail]<mailto:[e-mail]>
tel.: [phone]
[Visit technicolor.com]<http://www.technicolor.com/> [Visit i-speak-qeo.com] <http://www.i-speak-qeo.com/>
Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
www.technicolor.com<http://www.technicolor.com/> - www.i-speak-qeo.com<http://www.i-speak-qeo.com/>

[Follow Technicolor on Facebook]Facebook<http://www.facebook.com/TechnicolorCo>

[Follow Technicolor on Twitter]Twitter<http://twitter.com/TechnicolorCo>

[Follow Technicolor on YouTube]YouTube<http://www.youtube.com/technicolor>

[Follow Technicolor on LinkedIn]LinkedIn<http://www.linkedin.com/company/technicolor>


Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen
[Eco]

Help preserve the color of our world - Think before you print.