Hi Fred,
Le 22/04/2015 19:22, Templin, Fred L a écrit :
Hi Alex,
-----Original Message-----
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Sent: Wednesday, April 22, 2015 9:59 AM
To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org
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:alexandru.petre...@gmail.com]
Sent: Tuesday, April 21, 2015 12:42 PM
To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org
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:dmm-boun...@ietf.org]
On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03
PM To: Jouni Korhonen; dmm@ietf.org 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
fred.l.temp...@boeing.com
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
fred.l.temp...@boeing.com
Alex
Thanks - Fred fred.l.temp...@boeing.com
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 dmm@ietf.org <mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm
mailing list dmm@ietf.org <mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing
list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing
list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list
dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
