Subject: Re: [DMM] Mobility Exposure and Selection WT call

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Apr 2015 21:42:27 +0200

Le 31/03/2015 00:42, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message----- From: dmm [mailto:[email-masked]]
>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03
>> PM To: Jouni Korhonen; [email-masked] Subject: Re: [DMM] Mobility
>> Exposure and Selection WT call
>>
>> Le 26/03/2015 13:17, Jouni Korhonen a écrit :
>>> Alex,
>>>
>>> 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti:
>>>
>>> [snip]
>>>
>>>>> I thought by "fixed" you meant it stays the same wherever the
>>>>> Host goes (something like the Home Address).
>>>>
>>>> Alper - I think a LL address can also be qualified as 'fixed' -
>>>> it never changes.
>>>
>>> Does LL here mean link-local or link-layer? If it is the former
>>> one, then the above assertion is not correct.
>>
>> Link-local.
>>
>> And you seem to say a link-local address is not fixed?  I think
>> link-local addresses _are_ fixed set in stone.  They are formed
>> locally without need of help from router.
>
> AERO provides a fixed link-local address that is formed from a
> prefix received by DHCPv6 Prefix Delegation (PD).

Fred - but why should this ll prefix be provided by DHCP?  Is it of
variable value?  Or is the link-local constant all the time? (in which
case it could be hardcoded everywhere).

> Once the AERO Client is given a PD (either IPv6 or IPv4) it can form
> an AERO link-local address that stays the same wherever the Client
> moves and with no need to perform Duplicate Address Detection (DAD).
> It makes IPv6 ND simple and seamless.

Is that prefix fe80::/10?

Alex

>
> Thanks - Fred [email-masked]
>
>> Alex
>>
>>>
>>> - Jouni
>>>
>>>>
>>>> I think it's hard to disagree with that, no?
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> So, I guess, I should have referred to the "nomadic" address
>>>>> to mean the one that is constant, wherever the Host goes.
>>>>>
>>>>> As such, my suggestion is that a "nomadic" address can never
>>>>> be an RFC7217 address.
>>>>>
>>>>> In practice that would mean that if you configure an address
>>>>> to be "nomadic" you must also tell the kernel to not run
>>>>> RFC7217 on it.
>>>>>
>>>>> But ok, one might think that these two aspects ("nomadic" and
>>>>> RFC7217) are orthogonal at this point in time.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> I don't know if it makes sense to request a fixed and
>>>>>> random-based IP address. But if someone does it, it works.
>>>>>
>>>>>
>>>>>>
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> - configured by SLAAC, by DHCPv6, by PPP, or
>>>>>>>>> registered (RFC 6775).
>>>>>>>>>
>>>>>>>>
>>>>>>>> Orthogonal.
>>>>>>>>
>>>>>>>>
>>>>>>>>> E.g. a nomadic address could never be a link-local
>>>>>>>>> address.
>>>>>>>>>
>>>>>>>>>> #2. Describe how IP address type information is
>>>>>>>>>> conveyed from network to MN.
>>>>>>>>>
>>>>>>>>> If one designs a protocol to convey address type
>>>>>>>>> information from the network to the end node, then
>>>>>>>>> one could also add the other types mentioned above.
>>>>>>>>>
>>>>>>>>> SLAAC could never 'convey' the address type to the
>>>>>>>>> end-node, because SLAAC is an operation happening
>>>>>>>>> with as heavy weight from the Server (router) as from
>>>>>>>>> the Client (Host): the Router decides the prefix but
>>>>>>>>> the Client decides the Interface ID.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Still, the network can convey the type of IP address to
>>>>>>>> the host. Also, one can imagine augmenting Router
>>>>>>>> Solicitation to let the host convey its requested
>>>>>>>> type.
>>>>>>>
>>>>>>> I agree.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>>>> Address Registration Option of 6lo and BTLE would
>>>>>>>>> have the Host conveying this information to the
>>>>>>>>> Router (and not vice-versa).
>>>>>>>>>
>>>>>>>>
>>>>>>>> OK.
>>>>>>>>
>>>>>>>> Alper
>>>>>>>>
>>>>>>>>
>>>>>>>>> Yours,
>>>>>>>>>
>>>>>>>>> Alex
>>>>>>>>>
>>>>>>>>>> WT agreed to use draft-yegin-dmm-ondemand-mobility
>>>>>>>>>> as the baseline for item#1 (the API). A revision of
>>>>>>>>>> the draft will also include a new section to cover
>>>>>>>>>> backward compatibility (Danny will provide the
>>>>>>>>>> draft text). Comments on the draft are welcome.
>>>>>>>>>>
>>>>>>>>>> The next call will be about items #2/#3 (IP
>>>>>>>>>> address configuration enhancements associated with
>>>>>>>>>> the API). We intend to schedule that one in about 2
>>>>>>>>>> weeks.
>>>>>>>>>>
>>>>>>>>>> Alper
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote:
>>>>>>>>>>
>>>>>>>>>>> Folks,
>>>>>>>>>>>
>>>>>>>>>>> See below for the Webex details. Remember, the
>>>>>>>>>>> call is on Tue, Feb 10, at 4pm CET. And don't
>>>>>>>>>>> forget to read the documents in the reading list
>>>>>>>>>>> prior to the call.
>>>>>>>>>>>
>>>>>>>>>>>> Attendees _shall read _the following material
>>>>>>>>>>>> before the call so that we can directly jump to
>>>>>>>>>>>> the discussions:
>>>>>>>>>>>>
>>>>>>>>>>>> 1.
>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>
2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>>>>> 3.
>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>
4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>>>>> 5.
>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
Alper
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *DMM - Mobility Exposure and Selection WT*
>>>>>>>>>>> Tuesday 10 February 2015 16:00  |  Europe Time
>>>>>>>>>>> (Paris, GMT+01:00)  |  1 hr 30 min
>>>>>>>>>>>
>>>>>>>>>>>> *Join WebEx meeting*
>>>>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m1dad9871a277ff2ab142ae8ff4b77ad3>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>
Meeting number:641 085 326
>>>>>>>>>>>> Meeting password:dmm1911
>>>>>>>>>>>>
>>>>>>>>>>>> *Join by phone* *1-877-668-4493* Call-in toll
>>>>>>>>>>>> free number (US/Canada) *1-650-479-3208*
>>>>>>>>>>>> Call-in toll number (US/Canada) Access code:
>>>>>>>>>>>> 641 085 326 Toll-free calling restrictions
>>>>>>>>>>>> <http://www.webex.com/pdf/tollfree_restrictions.pdf>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Add this meeting
>>>>>>>>>>>> <https://ietf.webex.com/ietf/j.php?MTID=m0855d524ccb7239248d0ce34e19f38c8>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
to your calendar.
>>>>>>>>>>>>
>>>>>>>>>>>> Can't join the meeting? Contact support.
>>>>>>>>>>>> <https://ietf.webex.com/ietf/mc>
>>>>>>>>>>>>
>>>>>>>>>>>> IMPORTANT NOTICE: Please note that this WebEx
>>>>>>>>>>>> service allows audio and other information sent
>>>>>>>>>>>> during the session to be recorded, which may be
>>>>>>>>>>>> discoverable in a legal matter. By joining this
>>>>>>>>>>>> session, you automatically consent to such
>>>>>>>>>>>> recordings. If you do not consent to being
>>>>>>>>>>>> recorded, discuss your concerns with the host
>>>>>>>>>>>> or do not join the session.
>>>>>>>>>>>>
>>>>>>>>>>> <WebEx_Meeting.ics>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Poll is closed, and majority selected the
>>>>>>>>>>>> following date for the call:
>>>>>>>>>>>>
>>>>>>>>>>>> Feb 10, 4pm CET. 1,5hr call.
>>>>>>>>>>>>
>>>>>>>>>>>> Please mark your calendars.
>>>>>>>>>>>>
>>>>>>>>>>>> In this call, we'll aim making progress on the
>>>>>>>>>>>> I-D for item#1 (an API for source address
>>>>>>>>>>>> selection).
>>>>>>>>>>>>
>>>>>>>>>>>> Attendees _shall read _the following material
>>>>>>>>>>>> before the call so that we can directly jump to
>>>>>>>>>>>> the discussions:
>>>>>>>>>>>>
>>>>>>>>>>>> 1.
>>>>>>>>>>>> http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>
2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf
>>>>>>>>>>>> 3.
>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>>>>>>>>
4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf
>>>>>>>>>>>> 5.
>>>>>>>>>>>> http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
Alper
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jan 23, 2015, at 3:28 PM, Alper Yegin
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Folks,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please mark your availability on the
>>>>>>>>>>>>> following doodle for our next DMM WG Mobility
>>>>>>>>>>>>> Exposure and Selection WT call:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://doodle.com/7xgcr8x6cgxnbzur
>>>>>>>>>>>>>
>>>>>>>>>>>>> Register your availability no later than the
>>>>>>>>>>>>> end of Monday (Jan 26).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Alper
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________ dmm
>>>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________ dmm
>>>>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ dmm mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________ dmm mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>>>
>>
>>
>> _______________________________________________ dmm mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Apr 2015 16:51:34 +0000

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Tuesday, April 21, 2015 12:42 PM
> To: Templin, Fred L; Jouni Korhonen; [email-masked]
> Subject: Re: [DMM] Mobility Exposure and Selection WT call
> 

DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO
Client (e.g., 2001:db8:1:2::/64). The Client then constructs an
AERO link-local address from the prefix as fe80::2001:db8:1:2
(i.e., it embeds the 64-bit prefix from the prefix delegation in
the 64-bit interface identifier of an IPv6 link-local address).
Once the prefix delegation and AERO address configuration
are done, they stay fixes as long as the Client remains
associated with the same AERO link.

> Is that prefix fe80::/10?

No, it would be a global IPv6 prefix like 2001:db8:1:2::/64. The AERO link
has an associated AERO Service Prefix (e.g., 2001:db8::/32) from which
longer global IPv6 prefixes are delegated to each Client. The Client then
gets to keep and continually use its prefix delegation as long as it stays
associated with the same AERO link.

Thanks - Fred
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Apr 2015 18:59:16 +0200

> the 64-bit interface identifier of an IPv6 link-local address).

Fred, that looks weird.  Never saw a prefix to be used as an Interface 
Identifier.

I guess this breaks the DHCP prefix delegation specification.

Why does not the DHCPv6 server assign a link-local address altogether 
(rather than assigning a prefix, to be used as an IID).

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 22 Apr 2015 17:22:23 +0000

Hi Alex,

> Sent: Wednesday, April 22, 2015 9:59 AM

It is specified in the AERO document and also cited in RFC7421. There are
lots of weird "address within address" encapsulations in common use
within the IPv6 interface identifier (e.g., ISATAP address, etc.) and
this I think is in some ways less weird than some of the others.

> I guess this breaks the DHCP prefix delegation specification.

Not at all; I have running code that uses unmodified public domain
DHCPv6 clients and servers. On the server side, I was using ISC
DHCP but have recently moved over to a great new server package
called Kea (also from ISC).

> (rather than assigning a prefix, to be used as an IID).

Because the prefix length may be different than /64; hence, the
Client needs to receive the prefix in a DHCPv6 IA_PD option.

Thanks - Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 Apr 2015 18:35:52 +0200

Hi Fred,

> this I think is in some ways less weird than some of the others.

Ok.

> Client needs to receive the prefix in a DHCPv6 IA_PD option.

What if DHCP had an option to provide an Interface ID (instead of Prefix
Delegation)? Wouldnt that be more appropriate to form a link-local
address with that Interface ID?

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 24 Apr 2015 19:34:54 +0000

Hi Alex,

> Sent: Friday, April 24, 2015 9:36 AM

The great thing about the AERO address is that it can be used for both
IPv6 ND messaging and route determination. The AERO address is
guaranteed to be unique, so it can be used as the source address
of IPv6 ND messages with no need for DAD. It can also be used for
route determination without consulting a routing table.

Plus, we don't need any special options since DHCPv6 PD works
fine with no client or server modifications.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Apr 2015 09:45:12 -0400

> the 64-bit interface identifier of an IPv6 link-local address).

So, it is not actually a link-local address per the IPv6 Addressing
Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6).

Regards,
Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 15:53:27 +0000

Hi Brian,

> From: dmm [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: Monday, April 27, 2015 6:45 AM
> To: [email-masked]

Just because the AERO address Interface ID is not formed via EUI-64
does not mean that it is not a link-local address (see RFC7136, which
updates RFC4291). RFC7421 gives further commentary.

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Apr 2015 12:21:55 -0400

> updates RFC4291). RFC7421 gives further commentary.

I am not referring to the IID of the link-local address.  I am talking
about the 54 bits of zero which immediately follow the FE80::/10 prefix.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:30:19 +0000

Hi Brian,

> Sent: Monday, April 27, 2015 9:22 AM
> To: [email-masked]

AERO leaves those 54 bits as zero - are you seeing some place in the
spec where it does not appear that way?

Thanks - Fred

---

From: Brian Haberman <[email-masked]>
Date: Mon, 27 Apr 2015 12:36:19 -0400

> spec where it does not appear that way?

Apologies.  I read your example incorrectly.  As long as the prefix
delegated is 64 bits...

Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 27 Apr 2015 16:54:59 +0000

Hi Brian,

> Sent: Monday, April 27, 2015 9:36 AM
> To: [email-masked]

Yes, that is correct. The longest prefix AERO can delegate is /64. It
can however delegate shorter prefixes like /56, /48, etc.

Thanks - Fred