Re: [DMM] Mobility Exposure and Selection WT call

[Alexandru Petrescu <[e-mail]>]

Hi Fred,

Le 22/04/2015 19:22, Templin, Fred L a écrit :
> Hi Alex,
>
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:[e-mail]]
>> Sent: Wednesday, April 22, 2015 9:59 AM
>> To: Templin, Fred L; Jouni Korhonen; [e-mail]
>> Subject: Re: [DMM] Mobility Exposure and Selection WT call
>>
>> Le 22/04/2015 18:51, Templin, Fred L a écrit :
>>> Hi Alex,
>>>
>>>> -----Original Message-----
>>>> From: Alexandru Petrescu [mailto:[e-mail]]
>>>> Sent: Tuesday, April 21, 2015 12:42 PM
>>>> To: Templin, Fred L; Jouni Korhonen; [e-mail]
>>>> Subject: Re: [DMM] Mobility Exposure and Selection WT call
>>>>
>>>> Le 31/03/2015 00:42, Templin, Fred L a écrit :
>>>>> Hi Alex,
>>>>>
>>>>>> -----Original Message----- From: dmm [mailto:[e-mail]]
>>>>>> On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03
>>>>>> PM To: Jouni Korhonen; [e-mail] 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).
>>>
>>> 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).
>>
>> Fred, that looks weird.  Never saw a prefix to be used as an Interface
>> Identifier.
>
> 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.

Ok.

>> 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).
>
>> Why does not the DHCPv6 server assign a link-local address altogether
>> (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.

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

>
> Thanks - Fred
> [e-mail]
>
>> Alex
>>
>>> 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.
>>>
>>>>> 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?
>>>
>>> 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
>>> [e-mail]
>>>
>>>> Alex
>>>>
>>>>>
>>>>> Thanks - Fred [e-mail]
>>>>>
>>>>>> 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 [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________ dmm
>>>>>>>>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________ dmm mailing
>>>>>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________ dmm mailing
>>>>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/dmm
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ dmm mailing list
>>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>