Le 22/04/2015 18:51, Templin, Fred L a écrit :
Hi Alex,
-----Original Message-----
From: Alexandru Petrescu [mailto:[email protected]]
Sent: Tuesday, April 21, 2015 12:42 PM
To: Templin, Fred L; Jouni Korhonen; [email protected]
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:[email protected]]
On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03
PM To: Jouni Korhonen; [email protected] 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.
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
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
[email protected]
Alex
Thanks - Fred [email protected]
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 protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm
mailing list [email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing
list [email protected] https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing
list [email protected] https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list
[email protected] https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
