Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Francis Dupont <[EMAIL PROTECTED]> writes: >So I suppose there's draft, a pointer would help. Far from me any >intention that you imply, sorry. > > => draft-ietf-ipngwg-temp-addresses-v2-00.txt Thanks! >I think there's also MSRN but know nothing about it more than it's >used

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: > => please read the last update of RFC 3041 before to get things from > 3041 which are not in it... So I suppose there's draft, a pointer would help. Far from me any intention that you imply, sorry. => draft-ietf-ipngwg-temp-addresses-v2-00.

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Francis Dupont <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED]: >Ok, privacy, yes. > > => please read the last update of RFC 3041 before to get things from > 3041 which are not in it... So I suppose there's draft, a pointer would help. Far from me any intention that you imply, sorry. >

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Francis Dupont <[EMAIL PROTECTED]> writes: >>=> can I assume you didn't read draft-dupont-ipv6-imei-00.txt? >>(you should and I should have answered before :-) > => the question is addressed to Alexandru... I guess I have read it before I suggested an improvement on the coding of decimal

RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

PROTECTED] > Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? > > > Hello, > > > -Original Message- > > From: ext Alexandru Petrescu [mailto:[EMAIL PROTECTED]] > > [EMAIL PROTECTED] writes: > > > I would be a bit careful to use IM

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: > => what exactly do you mean by "reserve": > - make them not available at all? > - enforce some control/rules on availability? See my first email on the subject. The summary is: Reserve for future use; any future use requires an standards

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> > Yes. The use of 64 bit interface ID's is defined for prefixes 001 through > 111 ( except for multicast addresses), in RFC2373 "IP Version 6 Addressing > Architecture" published July 1998. See section 2.4. The text regarding > EUI-64 has been clarified in . Ooops... :-} I guess I read s

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> => what exactly do you mean by "reserve": > - make them not available at all? > - enforce some control/rules on availability? See my first email on the subject. The summary is: Reserve for future use; any future use requires an standards track RFC. > BTW I have an objection to the "IPv6 ove

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Markku, >I'm somewhat puzzled by this thread... has it been decided that IPv6 >address is 64+64, and that latter 64 is EUI-64 format interface ID for >all current and future IPv6 addresses? Yes. The use of 64 bit interface ID's is defined for prefixes 001 through 111 ( except for multicast add

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: I'm somewhat puzzled by this thread... has it been decided that IPv6 address is 64+64, and that latter 64 is EUI-64 format interface ID for all current and future IPv6 addresses? => this was decided for all unicast addresses which don't begin by 000

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

I'm somewhat puzzled by this thread... has it been decided that IPv6 address is 64+64, and that latter 64 is EUI-64 format interface ID for all current and future IPv6 addresses? If not, I cannot see what is the point of assigning these bits from EUI-64 and expect them to be valid for other ID fo

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: At 8:28 PM +0100 3/18/02, Francis Dupont wrote: > In your previous mail you wrote: > > Steve Deering <[EMAIL PROTECTED]> writes: > > The u bit in the current IID definition indicates whether or not the > > IID can be considered globally un

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

At 8:28 PM +0100 3/18/02, Francis Dupont wrote: > In your previous mail you wrote: > > Steve Deering <[EMAIL PROTECTED]> writes: > > The u bit in the current IID definition indicates whether or not the > > IID can be considered globally unique. > >=> can I assume you didn't read draft-dup

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: Not much email has followed on this topic so it isn't clear whether people are having too much fun debating other topics, think it is a good/bad idea, or just don't care. => what exactly do you mean by "reserve": - make them not available at all? -

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: You can see the results in http://search.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt. => the 3GPP/IPv6 DT seems to ignore this ID issue... The problem with IMEIs are that they are used in GSM, GPRS, and UMTS networks to screen stol

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: [EMAIL PROTECTED] writes: > I would be a bit careful to use IMEI as Interface Identifier. Hi Jonne, please let me assure you that I'm trying to be very careful in all this. If I speak out so frequently is just because I need to better understa

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: I would be a bit careful to use IMEI as Interface Identifier. I am not really sure if this is something you want to tell the whole world. => there is such a concern for ESD (CDMA 32 bit hardware ID) but nothing about IMEI. In fact IMEI is sent in clear by t

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

In your previous mail you wrote: Steve Deering <[EMAIL PROTECTED]> writes: > The u bit in the current IID definition indicates whether or not the > IID can be considered globally unique. => can I assume you didn't read draft-dupont-ipv6-imei-00.txt? (you should and I should have ans

RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

> > So I try something else than IMEI: IMSI. As IMEI is for phones, IMSI > is in the SIM cards. Is the IMSI private? Is it unique? IMSI is very unique, but alas very private. That should never be shown outside the mobile network. (IMSI=International Mobile Subscriber Identification, if I rem

RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

Hello, > -Original Message- > From: ext Alexandru Petrescu [mailto:[EMAIL PROTECTED]] > [EMAIL PROTECTED] writes: > > I would be a bit careful to use IMEI as Interface Identifier. > > Hi Jonne, please let me assure you that I'm trying to be very careful > in all this. If I speak out so

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

[EMAIL PROTECTED] writes: > I would be a bit careful to use IMEI as Interface Identifier. Hi Jonne, please let me assure you that I'm trying to be very careful in all this. If I speak out so frequently is just because I need to better understand how IPv6 and 3GPP/UMTS can be made to work togethe

RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

TECTED]] > Sent: Wednesday, March 13, 2002 12:02 PM > To: Steve Deering > Cc: Alberto Escudero-Pascual; Erik Nordmark; [EMAIL PROTECTED] > Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? > > > Steve Deering <[EMAIL PROTECTED]> writes: > >

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> ... it would limit home agents only to those hosts that have IPv6 > address format that mandate EUI-64 interface id. Wouldn't this prevent > using 6to4 address as home address? It would also exlude all > future non-EUI-64 address formats (or force everyone to use EUI-64). Markku, 6to4 address

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> From: Alberto Escudero-Pascual <[EMAIL PROTECTED]> > There is a quantitative and qualitative difference in reserving one > bit for RR or CryptoIID to enhance mobile security and even handover > performance or to reserve one bit (u) to "CLAIM" uniqueness. Uhh.. RR bit? I've not followed mobile

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Yesterday, i tried to estimate what is the probability of generating a random interface identifier that looks like a EUI-64 IID without using the 'u' bit at all calculating the worst of the cases. Let's take the worst of the cases, that all the EUI-64 based IPv6 current devices are in the same r

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Date:Wed, 13 Mar 2002 10:43:40 -0800 From:Steve Deering <[EMAIL PROTECTED]> Message-ID: | The u bit in the current IID definition indicates whether or not the | IID can be considered globally unique. If that were to be true,

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Steve, Let me clarify my point: u=0 => RFC3041, Manual, DHCPv6 or RFC2472 (4.1) RFC3041 => u=0 What i am trying to say is that despite that u=0 doesn't necessary mean that RFC3041 is in use. In practice, it could be the case that a high number of those IID are using RFC3041 and hence the an

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Steve Deering <[EMAIL PROTECTED]> writes: > The u bit in the current IID definition indicates whether or not the > IID can be considered globally unique. I'm trying to fit the IMEI into one of: Links or Nodes with IEEE EUI-64 Identifiers Links or Nodes with IEEE 802 48 bit MAC's

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

At 10:51 AM +0100 3/13/02, Alberto Escudero-Pascual wrote: >I want to stick to the question of Erik but i argue why nodes for example >that want to use a privacy extension (RFC3041) have to indicate that their >IID is not EUI-64 based and hence the use of the privacy extension is >observable. Alb

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

I agree of the potencial benefits of reserving bits in the IID for future "useful" use in the future, specialy in the mobility area. In that sense, i will like any references to EUI-64 based identifiers and the use of u/l bit being removed from 2473 as being already a proposal for making use of

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

"Michel Py" <[EMAIL PROTECTED]> writes: > >> Michel Py wrote: > >> IPv6 over ethernet: stick to exactly /64. Probably for TR and > >> FDDI too. > >> IPv6 over foo: it might be desirable to get a lower value > >> (make it fit on a nibble or byte boundary) _if_ accompanied > >> by RFC2373 modificat

RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

>> Michel Py wrote: >> IPv6 over ethernet: stick to exactly /64. Probably for TR and >> FDDI too. >> IPv6 over foo: it might be desirable to get a lower value >> (make it fit on a nibble or byte boundary) _if_ accompanied >> by RFC2373 modifications or new text that define a fixed >> aggregation b

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> One of the purposes of reserving this bit is to avoid "bidding down" > attacks in Mobile IPv6 binding update security, whereby an attacker > requests a less secure method so it can mount an attack. One issue that > comes to mind is that, by reducing the size of the address space, a > reserved b

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Erik, I might have missed this point, but let me ask the question just in case it hasn't been asked. One of the purposes of reserving this bit is to avoid "bidding down" attacks in Mobile IPv6 binding update security, whereby an attacker requests a less secure method so it can mount an attack. O

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

"Michel Py" <[EMAIL PROTECTED]> writes: > IPv6 over ethernet: stick to exactly /64. Probably for TR and FDDI > too. > IPv6 over foo: it might be desirable to get a lower value (make it > fit on a nibble or byte boundary) _if_ accompanied by RFC2373 > modifications or new text that define a fixed a

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Hi Erik, I'll pick the gauntlet, with great care :-) Erik Nordmark <[EMAIL PROTECTED]> writes: > > When other than Ethernet link layers are involved, probably the > > functionality of the u/g bits can be derived from the 8bit prefix? > > Maybe it's the 8bit prefix that should be tweaked to obtain

RE: Next steps on Reserving bits in RFC 2473 Interface IDs?

>> Alexandru Petrescu wrote: >> I'm very curious if the suggested recommendation is really >> "no more than 64" or is it "exactly 64"? > kre wrote: > It is currently probably exactly 64 - but there's no > reason for that. Actually, there are, but I will not get into that again. "more than 64" i

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Date:Tue, 12 Mar 2002 15:17:20 +0100 (CET) From:Erik Nordmark <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | The universal bit is defined in 2373bis (addr-arch-v3) to | apply to most of the address space, thus it is not tied to the link-layer | being Eth

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> Since u and g have approximately the same semantics that can be found > in the 8bit prefix of the addres I was believing that they're > necessary only for Ethernet-derived environments, where they can be > exploited by specific Ethernet optimizations for multicast, etc. The universal bit is de

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Date:12 Mar 2002 11:57:37 +0100 From:Alexandru Petrescu<[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I'm very curious if the suggested recommendation is really "no more | than 64" or is it "exactly 64"? It is currently probably exactly 64 - but there's no

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Erik Nordmark <[EMAIL PROTECTED]> writes: > I think our choices are: > 1. Do nothing > 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes >explicitly reserved. > 3. Reserve half of the IID space i.e. all addresses with group=1 become >explicitly reserved. Hi Erik, I h

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Robert Elz <[EMAIL PROTECTED]> writes: > 2373 should go no further than recommending that IPv6 over foo specs > should use no more than 64 bits as the interface ID. I'm very curious if the suggested recommendation is really "no more than 64" or is it "exactly 64"? Alex -

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

Date:Tue, 12 Mar 2002 11:20:06 +0200 From:Markku Savela <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | My opinion on this is: these ID related issues all belong to | IP-over-foo documents. The rfc-2373 should only talk about (prefix=n, | interface ID = 12

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

  Hello Erik, I really think this is an important topic Considering the MobileIP mailing discussions it would make sense to have an IID space reserved for "RR-addresses". I also believe that an IID space should also be reserved for CGA (Crypto. Generated ) addresses... I would therefore vote

Re: Next steps on Reserving bits in RFC 2473 Interface IDs?

> From: Erik Nordmark <[EMAIL PROTECTED]> > > A while back I sent an email to the list talking about > Reserving bits in RFC 2473 Interface IDs. rfc-2373 I presume... My opinion on this is: these ID related issues all belong to IP-over-foo documents. The rfc-2373 should only talk about (prefix