Re: [6lo] Draft applicability for 6775bis
On 4/20/2017 9:15 AM, Pascal Thubert (pthubert) wrote: > > What about : > > > > « > > This implies that a 6LR or 6LBR which is intended to support N > hosts MUST have space to register at least on the order of 10N IPv6 > addresses. > > « > > -> > > « > > This implies that the capabilities of 6LR and 6LBRs in terms of > number of registrations must be clearly announced in the router > documentation, and that a network administrator should deploy adapted > 6LR/6LBRs to support the number and type of devices in his network, > based on the number of IPv6 addresses that those devices require. > > « > > > > Works ? > I don't have a strong opinion on this wording, but I have a recommendation for the authors of the draft. This discussion outlined a couple of concerns about potential abuses. For example, I noted the following: 1) Registration procedure could be used to deny access, by abusing the administrative rejection option. 2) Nodes registering a large number of IID could overwhelm the registration system. I would also add a generic concern about unique identifiers and privacy. This is an obvious concern in mobility scenarios, but even for static networks it also is a concern if the option can be observed outside the network. I understand that the encrypted link provides some mitigation, but having provisions to vary the IID over time would be even better. It might be a good idea to document these issues in the security considerations. -- Christian Huitema ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
What about : « This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses. « -> « This implies that the capabilities of 6LR and 6LBRs in terms of number of registrations must be clearly announced in the router documentation, and that a network administrator should deploy adapted 6LR/6LBRs to support the number and type of devices in his network, based on the number of IPv6 addresses that those devices require. « Works ? Pascal From: Lorenzo Colitti [mailto:lore...@google.com] Sent: jeudi 20 avril 2017 11:52 To: Gabriel Montenegro Cc: Pascal Thubert (pthubert) ; Erik Nordmark ; huitema ; draft-ietf-6lo-rfc6775-upd...@ietf.org; Suresh Krishnan ; 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis Thanks for writing this up. The text is very helpful. In the general case, I'm not sure 10N is a reasonable recommendation. RFC 7934 section 7 discusses at some length the question of how many addresses are necessary, and the conclusion is "in general it is not possible to estimate in advance how many addresses are required". For a constrained 6lo network, 10N seems reasonable. However, one of the concerns I have with RFC6775bis is this text: Efficiency aware IPv6 Neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND [RFC6775] can be extended to other types of links beyond IEEE std 802.15.4 for which it was defined. The registration technique is beneficial when the Link-Layer technique used to carry IPv6 multicast packets is not sufficiently efficient in terms of delivery ratio or energy consumption in the end devices, in particular to enable energy-constrained sleeping nodes. The value of such extension is especially apparent in the case of mobile wireless nodes, to reduce the multicast operations that are related to classical ND ([RFC4861], [RFC4862]) and plague the wireless medium. This serves scalability requirements listed in Appendix A.6. I don't think this is good guidance for general purpose networks. On a less-constrained device such as a phone connected to a less-constrained network such as 802.11, ethernet, or LTE, I certainly wouldn't want to be limited to 10 addresses. This is why RFC 7934 section 7 does not give a recommendation for number of addresses per host, saying instead that the network should be able to provide as many as necessary. A registration-based mechanism is fundamentally different from an opportunistic mechanism in that the scalability is determined by the number of configured addresses, not the number of active addresses. For example: on 802.11, for example, my device can configure 100, 1000, or 100 addresses in the same solicited-node multicast group (there are 2^40 addresses there, so there's plenty of space), and nothing in the network will experience any load, until those addresses are used and have to be in some router's neighbour cache. And if the neighbour cache were to implement implement per-MAC address thresholds it would be possible to switch addresses very frequently I don't think we should say that 6LoWPAN ND can be extended to other links without having good text on how to make a trade-off between the scalability benefits that it claims and the address availability benefits that it gives up. On Thu, Apr 20, 2017 at 7:12 AM, Gabriel Montenegro mailto:gabriel.montene...@microsoft.com>> wrote: > Please let me know if the text below is OK (you may leverage the ticket); > I'll time > out and post by the end of week. Thanks Pascal, looks good. Lorenzo? Unless we hear otherwise, we can think about WG LC perhaps as early as next week. Thanks, Gabriel (on behalf of chairs) ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
Either way works for me. I’m happy with Lorenzo’s code. I’m also happy to have with this and a ”pure garbage” return code, if folks find useful to make that distinction. Comments? Pascal From: Lorenzo Colitti [mailto:lore...@google.com] Sent: jeudi 20 avril 2017 12:03 To: Pascal Thubert (pthubert) Cc: Erik Nordmark ; Christian Huitema ; Brian Haberman ; 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis I think so. the unspecified address is certainly not topologically correct because it's not in the right /64. In general, random garbage has only one chance in 2^64 of being topologically correct. :-) On Thu, Apr 20, 2017 at 7:00 PM, Pascal Thubert (pthubert) mailto:pthub...@cisco.com>> wrote: Hello Lorenzo: Say the user registers, say, unspecified, is “Address topologically incorrect” the right thing? I can add that code, but how do you return that the requester asks for pure garbage? Take care, Pascal From: Lorenzo Colitti [mailto:lore...@google.com<mailto:lore...@google.com>] Sent: jeudi 20 avril 2017 11:55 To: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>> Cc: Erik Nordmark mailto:nordm...@sonic.net>>; Christian Huitema mailto:huit...@huitema.net>>; Brian Haberman mailto:br...@innovationslab.net>>; 6lo@ietf.org<mailto:6lo@ietf.org> Subject: Re: [6lo] Draft applicability for 6775bis On Wed, Apr 5, 2017 at 1:15 AM, Pascal Thubert (pthubert) mailto:pthub...@cisco.com>> wrote: I also removed the administrative rejection, the return codes are now as follows: [...] | 8 | Invalid Registered Address: The address being registered | | | is not usable on this link, e.g. it is not topologically | | | correct | As worded, it's not clear to me how this option is substantially different from the administrative rejection option. Could it be scoped more tightly, e.g., renamed to "Address topologically incorrect"? ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
I’m wondering whether we should propose a guidance at all. I think the aim was in the ‘at least’, indicating that less than that would be a bad idea, but not giving an upper bar. That’s an admin/ best practice thing. Basically a device supports so many registrations, and the network admin must provide enough such devices to support his network. The devices I’m used to allow to configure such a bar (for SAVI purpose) - I mean there nothing new there, SAVI was there first - and the goal is really to protect the switch/router against ddos. What do others think? From: Lorenzo Colitti [mailto:lore...@google.com] Sent: jeudi 20 avril 2017 11:52 To: Gabriel Montenegro mailto:gabriel.montene...@microsoft.com>> Cc: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; Erik Nordmark mailto:nordm...@sonic.net>>; huitema mailto:huit...@huitema.net>>; draft-ietf-6lo-rfc6775-upd...@ietf.org<mailto:draft-ietf-6lo-rfc6775-upd...@ietf.org>; Suresh Krishnan mailto:suresh.krish...@ericsson.com>>; 6lo@ietf.org<mailto:6lo@ietf.org> Subject: Re: [6lo] Draft applicability for 6775bis Thanks for writing this up. The text is very helpful. In the general case, I'm not sure 10N is a reasonable recommendation. RFC 7934 section 7 discusses at some length the question of how many addresses are necessary, and the conclusion is "in general it is not possible to estimate in advance how many addresses are required". For a constrained 6lo network, 10N seems reasonable. However, one of the concerns I have with RFC6775bis is this text: Efficiency aware IPv6 Neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND [RFC6775] can be extended to other types of links beyond IEEE std 802.15.4 for which it was defined. The registration technique is beneficial when the Link-Layer technique used to carry IPv6 multicast packets is not sufficiently efficient in terms of delivery ratio or energy consumption in the end devices, in particular to enable energy-constrained sleeping nodes. The value of such extension is especially apparent in the case of mobile wireless nodes, to reduce the multicast operations that are related to classical ND ([RFC4861], [RFC4862]) and plague the wireless medium. This serves scalability requirements listed in Appendix A.6. I don't think this is good guidance for general purpose networks. On a less-constrained device such as a phone connected to a less-constrained network such as 802.11, ethernet, or LTE, I certainly wouldn't want to be limited to 10 addresses. This is why RFC 7934 section 7 does not give a recommendation for number of addresses per host, saying instead that the network should be able to provide as many as necessary. A registration-based mechanism is fundamentally different from an opportunistic mechanism in that the scalability is determined by the number of configured addresses, not the number of active addresses. For example: on 802.11, for example, my device can configure 100, 1000, or 100 addresses in the same solicited-node multicast group (there are 2^40 addresses there, so there's plenty of space), and nothing in the network will experience any load, until those addresses are used and have to be in some router's neighbour cache. And if the neighbour cache were to implement implement per-MAC address thresholds it would be possible to switch addresses very frequently I don't think we should say that 6LoWPAN ND can be extended to other links without having good text on how to make a trade-off between the scalability benefits that it claims and the address availability benefits that it gives up. On Thu, Apr 20, 2017 at 7:12 AM, Gabriel Montenegro mailto:gabriel.montene...@microsoft.com>> wrote: > Please let me know if the text below is OK (you may leverage the ticket); > I'll time > out and post by the end of week. Thanks Pascal, looks good. Lorenzo? Unless we hear otherwise, we can think about WG LC perhaps as early as next week. Thanks, Gabriel (on behalf of chairs) ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
Hello Lorenzo: Say the user registers, say, unspecified, is “Address topologically incorrect” the right thing? I can add that code, but how do you return that the requester asks for pure garbage? Take care, Pascal From: Lorenzo Colitti [mailto:lore...@google.com] Sent: jeudi 20 avril 2017 11:55 To: Pascal Thubert (pthubert) Cc: Erik Nordmark ; Christian Huitema ; Brian Haberman ; 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis On Wed, Apr 5, 2017 at 1:15 AM, Pascal Thubert (pthubert) mailto:pthub...@cisco.com>> wrote: I also removed the administrative rejection, the return codes are now as follows: [...] | 8 | Invalid Registered Address: The address being registered | | | is not usable on this link, e.g. it is not topologically | | | correct | As worded, it's not clear to me how this option is substantially different from the administrative rejection option. Could it be scoped more tightly, e.g., renamed to "Address topologically incorrect"? ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
> Please let me know if the text below is OK (you may leverage the ticket); > I'll time > out and post by the end of week. Thanks Pascal, looks good. Lorenzo? Unless we hear otherwise, we can think about WG LC perhaps as early as next week. Thanks, Gabriel (on behalf of chairs) ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
Dear all: FWIW, I also created a ticket https://trac.ietf.org/trac/6lo/ticket/20 to track the issue. Please let me know if the text below is OK (you may leverage the ticket); I'll time out and post by the end of week. Take care, Pascal -Original Message- From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: mardi 4 avril 2017 18:16 To: Erik Nordmark ; Christian Huitema ; Lorenzo Colitti Cc: Brian Haberman ; 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis Dear all: I retrofitted the text with minors editions as follows: " 2. Applicability The purpose of the Address Registration Option (ARO) option [RFC6775] and the Extended ARO (EARO) option that is introduced in this document is to facilitate duplicate address detection (DAD) for hosts and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to reduce the need for sending multicast neighbor solicitations and also to be able to support backbone routers. In some cases the address registration can fail or be useless for reasons other than a duplicate address. Examples are the router having run out of space, a registration bearing a stale sequence number (e.g. denoting a movement of the host after this registration was placed), a host misbehaving and attempting to register an invalid address such as the unspecified address [RFC4291], or the host using an address which is not topologically correct on that link. In such cases the host will receive an error to help diagnose the issue and may retry, possibly with a different address, and possibly registering to a different 6LR, depending on the returned error. However, the ability to return errors to address registrations MUST NOT be used to restrict the ability of hosts to form and use addresses as recommended in Host Address Availability Recommendations [RFC7934]. In particular, this is needed for enhanced privacy, which implies that each host will register a multiplicity of address as part mechanisms like Privacy Extensions for Stateless Address Autoconfiguration (SLAAC) in IPv6 [RFC4941]. This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses. " I also removed the administrative rejection, the return codes are now as follows: " +---+---+ | Value | Description | +---+---+ | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate| | | Address" applies to the Registered Address. If the Source | | | Address conflicts with an existing registration, | | | "Duplicate Source Address" should be used instead | | | | | 3 | Moved: The registration fails because it is not the | | | freshest | | | | | 4 | Removed: The binding state was removed. This may be | | | placed in an asynchronous NS(ARO) message, or as the | | | rejection of a proxy registration to a Backbone Router| | | | | 5 | Proof requested: The registering node is challenged for | | | owning the registered address or for being an acceptable | | | proxy for the registration| | | | | 6 | Duplicate Source Address: The address used as source of | | | the NS(ARO) conflicts with an existing registration. | | | | | 7 | Invalid Source Address: The address used as source of the | | | NS(ARO) is not usable on this link, e.g. it is not| | | topologically correct | | | | | 8 | Invalid Registered Address: The address being registered | | | is not usable on this link, e.g. it is not topologically | | | correct | +---+---+ " Does that work? Take care, Pascal -Original Message- From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Brian Haberman Sent: mardi 4 avril 2017 16:42 To: 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis On 4/4/17 10:02 AM, Suresh Krishnan wrote: > Hi Dave, > >> On Mar 29, 2017, at 1:47 PM, Dave
Re: [6lo] Draft applicability for 6775bis
Dear all: I retrofitted the text with minors editions as follows: " 2. Applicability The purpose of the Address Registration Option (ARO) option [RFC6775] and the Extended ARO (EARO) option that is introduced in this document is to facilitate duplicate address detection (DAD) for hosts and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to reduce the need for sending multicast neighbor solicitations and also to be able to support backbone routers. In some cases the address registration can fail or be useless for reasons other than a duplicate address. Examples are the router having run out of space, a registration bearing a stale sequence number (e.g. denoting a movement of the host after this registration was placed), a host misbehaving and attempting to register an invalid address such as the unspecified address [RFC4291], or the host using an address which is not topologically correct on that link. In such cases the host will receive an error to help diagnose the issue and may retry, possibly with a different address, and possibly registering to a different 6LR, depending on the returned error. However, the ability to return errors to address registrations MUST NOT be used to restrict the ability of hosts to form and use addresses as recommended in Host Address Availability Recommendations [RFC7934]. In particular, this is needed for enhanced privacy, which implies that each host will register a multiplicity of address as part mechanisms like Privacy Extensions for Stateless Address Autoconfiguration (SLAAC) in IPv6 [RFC4941]. This implies that a 6LR or 6LBR which is intended to support N hosts MUST have space to register at least on the order of 10N IPv6 addresses. " I also removed the administrative rejection, the return codes are now as follows: " +---+---+ | Value | Description | +---+---+ | 0..2 | See [RFC6775]. Note that a Status of 1 "Duplicate| | | Address" applies to the Registered Address. If the Source | | | Address conflicts with an existing registration, | | | "Duplicate Source Address" should be used instead | | | | | 3 | Moved: The registration fails because it is not the | | | freshest | | | | | 4 | Removed: The binding state was removed. This may be | | | placed in an asynchronous NS(ARO) message, or as the | | | rejection of a proxy registration to a Backbone Router| | | | | 5 | Proof requested: The registering node is challenged for | | | owning the registered address or for being an acceptable | | | proxy for the registration| | | | | 6 | Duplicate Source Address: The address used as source of | | | the NS(ARO) conflicts with an existing registration. | | | | | 7 | Invalid Source Address: The address used as source of the | | | NS(ARO) is not usable on this link, e.g. it is not| | | topologically correct | | | | | 8 | Invalid Registered Address: The address being registered | | | is not usable on this link, e.g. it is not topologically | | | correct | +---+---+ " Does that work? Take care, Pascal -Original Message- From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Brian Haberman Sent: mardi 4 avril 2017 16:42 To: 6lo@ietf.org Subject: Re: [6lo] Draft applicability for 6775bis On 4/4/17 10:02 AM, Suresh Krishnan wrote: > Hi Dave, > >> On Mar 29, 2017, at 1:47 PM, Dave Thaler >> wrote: >> >> Any issue with a standards track document having a normative >> reference to a BCP? > > No issues that I know of. The downref rules seem to be pointing > *from* Standards track and BCP documents *to* lower maturity level > documents as per RFC3967. Just to be safe, I can still call this out > in the IETF last call if the WG decides to go that way. Right. ST and BCP are at the same level, so there are no down-ref issues with a normative reference. Those i
Re: [6lo] Draft applicability for 6775bis
On 4/4/17 10:02 AM, Suresh Krishnan wrote: > Hi Dave, > >> On Mar 29, 2017, at 1:47 PM, Dave Thaler >> wrote: >> >> Any issue with a standards track document having a normative >> reference to a BCP? > > No issues that I know of. The downref rules seem to be pointing > *from* Standards track and BCP documents *to* lower maturity level > documents as per RFC3967. Just to be safe, I can still call this out > in the IETF last call if the WG decides to go that way. Right. ST and BCP are at the same level, so there are no down-ref issues with a normative reference. Those issues arise when ST or BCP documents normatively reference Info and Experimental documents. signature.asc Description: OpenPGP digital signature ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
Hi Dave, > On Mar 29, 2017, at 1:47 PM, Dave Thaler wrote: > > Any issue with a standards track document having a normative reference to a > BCP? No issues that I know of. The downref rules seem to be pointing *from* Standards track and BCP documents *to* lower maturity level documents as per RFC3967. Just to be safe, I can still call this out in the IETF last call if the WG decides to go that way. > If so, then could reword so that the MUST NOT is not in the same sentence as > the BCP reference, e.g. > >> However, the ability to return errors to address registrations MUST NOT be >> used to restrict the ability of hosts to form and use addresses. See >> [RFC7934] >> for further discussion. > > If there is no issue in having a normative reference to a BCP then I think > Erik's text is fine. I have no problems with this text either as it cleanly decouples the requirement from the background. Thanks Suresh smime.p7s Description: S/MIME cryptographic signature ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
Hello Erik Superb! On this particular sentence " Example are the router having run out of space, the host having a stale sequence number, or the host is using an address which does not match the prefix(es) for the link. In such cases the host will receive an error to help diagnose the issue and retry. " I'd suggest: " Examples are the router having run out of space, a registration bearing a stale sequence number (e.g. denoting a movement of the host after this registration was placed), a host misbehaving and attempting to register an invalid address such as the UNSPECIFIED addresses, or the host using an address which is not topologically correct on that link. In such cases the host will receive an error to help diagnose the issue and may retry, possibly with a different address, and possibly via a different 6LR. " Regards, Pascal > Le 29 mars 2017 à 10:49, Erik Nordmark a écrit : > > Example are the router having run out of space, the host having a stale > sequence number, or the host is using an address which does not match the > prefix(es) for the link. In such cases the host will receive an error to help > diagnose the issue and retry. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Draft applicability for 6775bis
Any issue with a standards track document having a normative reference to a BCP? If so, then could reword so that the MUST NOT is not in the same sentence as the BCP reference, e.g. > However, the ability to return errors to address registrations MUST NOT be > used to restrict the ability of hosts to form and use addresses. See > [RFC7934] > for further discussion. If there is no issue in having a normative reference to a BCP then I think Erik's text is fine. Dave > -Original Message- > From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Erik Nordmark > Sent: Wednesday, March 29, 2017 10:50 AM > To: Lorenzo Colitti ; huitema > > Cc: 6lo@ietf.org > Subject: [6lo] Draft applicability for 6775bis > > > Here is an attempt at an applicability statement based on what we talked > about today. > It is sufficiently strong? > Other RFCs or drafts that we should reference? > > Erik > > > > Applicability > > The purpose of the ARO and EARO is to facilitate duplicate address detection > for hosts and pre-populate NCEs in the routers to reduce the need for > sending multicast neighbor solicitations and also to be able to support > backbone routers. > > In some cases the address registration can fail or be useless for reasons > other > than a duplicate address. Example are the router having run out of space, the > host having a stale sequence number, or the host is using an address which > does not match the prefix(es) for the link. In such cases the host will > receive > an error to help diagnose the issue and retry. > > However, the ability to return errors to address registrations MUST NOT be > used to restrict the ability of hosts to form and use addresses as specified > in > [RFC7934]. In particular, this is needed for enhanced privacy, which implies > that each host will register a multiplicity of address as part mechanisms like > [RFC4941]. This implies that a 6LR or 6LBR which is intended to support N > hosts MUST have space to register at least on the order of 10N IPv6 > addresses. > > --- > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
