Re: [DMM] Mobility Exposure and Selection WT call

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

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[e-mail]]
> Sent: Friday, April 24, 2015 9:36 AM
> To: Templin, Fred L; Jouni Korhonen; [e-mail]
> Subject: Re: [DMM] Mobility Exposure and Selection WT call
> 
> 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?

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
[e-mail]

> 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
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>