RE: RFC7084

[Wuyts Carl <[e-mail]>]

Sorry Barbara,

But I still don't agree.
I read below:
""
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.
""
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 be "numbered" flag, in this case, make it N=1! If we keep bending all kind of rules for the sake of access networks, or whatever other reason, then let's just stop making standards completely, as they serve no goal.  If today one reads IPv6 RFCs, (s)he will never map M=1 to ia_na request or not, and this is how it should be.
So, why not just ask all options all together then ?  the access network can cope, and no matter what you ask, something will be served !!

Stop pleasing setting these silly requirements.  The "if prefix is too small" req was already very badly phrased, but this is a lot worse.
I hear on congresses that "the CPE router" is often a problem in v6 deployment, although not that much anymore recently, but please consider it as a mature device in the network, not let it bending all kind of rules for whatever sake.
Standards are defined for a reason, so let's all stick to it please, and not "tweaking" them for whatever reason.  If you want the CPE to ask ia_na, fine with me, but then create the statement to ask for it ALL the time, not just because of M=1 setting.

Please note we merely operate in a managed CPE-environment, so know upfront whether ia_na is needed or not, but you here state that the access network is dictating the M=1 to be translated by ANY CPE router as" ask ia_na.   this can only be handled by vendors by ALWAYS asking ia_na I'm afraid.  Please stop glueing things together which are not serving any real goal.  Keep it simple.  If you always want ia_na, fine with me, but make a req to just ask ia_na rather than to bind it to the wrong flag.

Just FYI.  A lot of our customers don't even use ia_na.  And yes, they are using M=1, nearly all of them.

Regs
Carl


From: ipv6 [mailto:[e-mail]] On Behalf Of STARK, BARBARA H
Sent: maandag 9 december 2013 16:02
To: Wuyts Carl; <[e-mail]>
Subject: RE: RFC7084

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]<mailto:[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.