Hi Jouni, I understand this is not the forum to discuss 3GPP modifications. The information in the draft is based on information from multiple sources who believe that 3GPP IPv6 equipments(routers) often support DAD and periodic router advertisements for ND implementations.
Please take a look at section 9.2.1.1 of TS23.060. dated 03-2012. Can you confirm that 3GGP specifications mandates NOT to do periodic RA or DAD? The spec does refer to RFC4861 which is being modified by efficient-nd. > > ==> Yes. It should just say 3GPP Cellular Networks. Looking at TS 23.060 and > TS 123.401 I see that the former allows periodic RA. Though TS 123.401 stays > silent about periodic RA, and it talks about RS->RA sequence and DAD not > being required for SLAAC. However, it is unclear if the RA is unicast or > multicast and does not prevent one implementation to send periodic RA. If these procedures are unclear, you should read RFC6459 and draft-ietf-v6ops-rfc3316bis. Anyway, 3GPP system sends periodic unsolicited RAs and state-3 also says to do so. Typically the router lifetimes are just set long, measured in hours. Whether the RA is multicast or unicast does not matter. The underlying 3GPP point-to-point link does not support userplane multicast anyway and each node will receive their (unicast) copy of the RA. Each link acts independently. ===> RFC6459 and draft-ietf-v6ops-rfc3316bis are "informational" and provides guidance based on the current IPv6 behavior. For example, rfc3316bis draft states: "Thus, the host is not required to perform Duplicate Address Detection on the cellular interface." Efficient-nd provides an example of cellular networks for the standardized optimization - though it is up to 3GPP to adopt that. Efficient-nd is primarily intended for shared subnet networks same as RFC4861. > The I-D does not add more ND traffic at all. The registration procedure is an > optional feature and it is also embedded in NUD like message and one can set > a long lifetime to avoid frequent registration. >> Ok. Thanks for pointing the optionality. Missed that. If the registration is >>optional, then what is the benefit? My point is that trying to optimize ND >>over >> 3GPP link any further is likely a wasted effort. As of today, there >>is no DAD or >>address resolution, router does not do NUD for global >>addresses and periodic Ras >> are seldom. ===> The registration is optional because one has to provide backward compatibility with RFC4861 hosts. It is the same way as any optimization enhancement works. "Periodic RA are seldom" is a subjective term when TS23.060 allows that. Note that efficient-nd is not an informational document and it is updating RFC4861. [ similar to RFC 6775 but for regular IPv6 networks] >> Also, the optimization in the I-D seems to depend on an unique ID (EUI-64 or >>equivalent). That does not hold in 3GPP system, since such are not mandated >>from >>3GPP UEs. There is also MUST for SLLA when ARO is used, however, 3GPP >>links do not >> have link-layer addressing. ===> How does 3GPP form a IPv6 address? What is the ESD part? Does not it associate each device with a unique identification? Good point on the SLLA usage on ARO. Will look into that. > Thanks for your input. >> Thanks. I am just trying to get my head around this. Current statements for >>usability in cellular just seem superficial at the moment. For example, >>currently >> I cannot agree Section 16.4. (when it comes to cellular). ===> So, is your point that this document is NOT applicable for cellular networks? Do you want us to modify the text in 16.4 or remove cellaur part in 16.4? I am not quite clear what exactly you're trying to accomplish. The document is referring cellular networks as an example. -Samita > > > On Nov 22, 2012, at 2:04 AM, Samita Chakrabarti wrote: > >> Hello All: >> >> As a follow-up from the IETF85 6man meeting presentation on >> Efficient-nd draft, we have posted a new version of the document which >> incorporated comments from Carsten Bormann in the list on editorial changes >> and some more clarification and editorial changes based on individual >> comments. >> >> More comments are welcome in improving the document. >> >> Regards, >> -Samita >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
