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