Re: [v6ops] Next step? [Re: The bottom is /112]

["Templin (US), Fred L" <[e-mail]>]

Mark, my initial description was purposefully light on details but to get the full picture
you can have a look at the following draft:

https://datatracker.ietf.org/doc/draft-templin-6man-lla-type/

The idea for this LLA-based PD scheme is as follows:

1) The requesting router creates a temporary LLA using RFC4941(bis) and sets a prefix length
indication inside the LLA itself. The RR then uses the LLA as the IPv6 source address of an RS
message to send to the delegating router.

2) When the delegating router receives the RS, it sees that the IPv6 source is an RFC4941(bis)
address with a non-zero prefix length indication. The DR then coordinates with the DHCPv6
server to request a PD of the length indicated by the RR.

3) When the DR receives the PD from the DHCPv6 server, it creates an OMNI LLA by
embedding the delegated prefix in the IID of fe80::/64, e.g., as fe80::2001:db8:1:2.
The DR then sets a prefix length indication in the OMNI LLA, and sets the LLA as the
destination address of an RA message to send back to the RR.

4) When the RR receives the RA message, it sees that the destination is an OMNI LLA
with a non-zero prefix length. The RR then uses the embedded prefix within the OMNI
LLA as its delegated prefix, and regards the Router Lifetime as the time at which the
delegated prefix needs to be renewed.

You also asked about the long-lived usage of unique LLAs, and I think what we need
to consider is that IPv6 interfaces may configure multiple LLAs of multiple different
types. The types need to be coordinated so that they do not collide with one another
and cause duplication. All of this is explained in the draft cited above.

Thanks - Fred


From: Mark Smith [mailto:[e-mail]]
Sent: Sunday, November 22, 2020 12:10 PM
To: Templin (US), Fred L <[e-mail]>
Cc: Ca By <[e-mail]>; Brian E Carpenter <[e-mail]>; IPv6 Operations <[e-mail]>; 6MAN <[e-mail]>
Subject: Re: [EXTERNAL] Re: [v6ops] Next step? [Re: The bottom is /112]


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.





On Mon, 23 Nov 2020, 01:59 Templin (US), Fred L, <[e-mail]<mailto:[e-mail]>> wrote:
Hi, I believe the AERO/OMNI approach to prefix delegation would be good for the 3GPP
case also. The approach is predicated on the router returning an RA with an IPv6 link-local
destination address determined by the delegated prefix. The link-local address is formed
by writing the most significant 64 bits of the delegated prefix into the interface ID of the
prefix fe80::/64.

For example, if the delegated prefix were 2001:db8:1:0::/56 then the IPv6 link-local
destination address is fe80::2001:db8:1:0. This provides at least two important
operational advantages.

1) It conveys the delegated prefix in the IPv6 destination address of the RA so that
no PIOs inside the RA need to be used for prefix delegation.

In my operational experience it is far better to make things explicit in packets rather than implicit.

See RFC8469 for an example of where what was implicit in packets has caused so many problems that now being explicit has become the recommendation. (Absence of this in a wholesaler's network caused us and a customer months of troubleshooting for unusual performance problems, and is now costing us service outages for many customers at once while they put it in place.)



2) It supplies the mobile node with a guaranteed-unique link-local address that
it can use for future communications without the need to perform DAD.


So the RA DA is carries both delegated prefix information and with link-local address configuration too? How does a node know to use the RA DA as its link-local address?

With the rise of wireless we need to care about the global traceability of link-local addresses too. Persistent, globally unique link-local IIDs have the same privacy implications as persistent globally unique WiFi MAC addresses and Bluetooth MAC addresses.

Have a look at https://wigle.net and the Android app for collecting the data.

A similar app focused on Bluetooth is Ramble.

Neither of these apps require a hacked phone, the can just be installed and run by anybody from the Google app store.


Again, the proposal comes from the AERO/OMNI use case, but I believe is also
good for 3GPP and really any other wireless use case where a lightweight
prefix delegation capability is desired.

Fred