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?

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?

> 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: IPV6_JOIN_GROUP for v4 multicast

> On Thu, 14 Mar 2002 07:33:54 +0200 (EET), > Pekka Savola <[EMAIL PROTECTED]> said: >> > And I would suggest that the same arguments still apply to multicast >> > addresses as well. Otherwise this topic would not keep reappearing. If >> > as you say, the arguments don't buy much for m

Re: IPv6-support-for-what-exists-today (Was: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?])

"Charles E. Perkins" <[EMAIL PROTECTED]> writes: > That's exactly right, and I am suggesting that the draft > be renamed to be "IPv6-support-for-what-exists-today". Hi, appologies for a more than week old follow-up and this has probably been mentioned. Being confronted recently with the idea of

Re: IPv6-support-for-what-exists-today (Was: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?])

On Thu, Mar 14, 2002 at 04:23:17PM +0100, Alexandru Petrescu wrote: > For example, how about better separating IPv6-over-Ethernet rfc2464 > from the current address architecture draft of rfc2373? My precise > suggestion would be to move EUI-64 and Modified EUI-64 from the latter > to the former

Re: IPv6-support-for-what-exists-today

Ignatios Souvatzis <[EMAIL PROTECTED]> writes: > The idea is to use the same 64bit Interface Identifier (especially > if a globally unique, e.g., derived from the EUI-64 of the node, if > available, or the EUI-64 of one of the Ethernet devices) also for an > interface on a different link that has

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: Securing Neighbor Discovery

Pekka, > I completely agree. Additionally, I'd like to see an > infrastructureless solution to be used anywhere possible. > Why? Basically because an infrastructureless solution means > that we can make it to work with zero configuration, while > any infrastructure necessarily needs that either

Re: Securing Neighbor Discovery

James Kempf wrote: > The upshot of what I am saying is that I believe this is not a > purely > technical problem. There are sociological and business aspects > of it that suggest a solution which leverages off the existing > authentication/business infrastructure is likely to be more of interest

Re: Securing Neighbor Discovery

Jari, So, this is getting a little off topic for this list, perhaps we should move the discussion elsewhere? Final comments below. > However, I wouldn't like to design the Internet _just_ for > the ISPs and the commercial providers. If I'm a small business > or a home, I want to set-up my netwo

Re: IPV6_JOIN_GROUP for v4 multicast

> Who wants an application that can work _only_ with IPv6? Nobody. strongly disagree. IPv6 provides capabilities that simply don't exist in IPv4 - among them the ability to provide large numbers of stable addresses. In other words, IPv6 enables applications that cannot be widely deployed under

Re: IPV6_JOIN_GROUP for v4 multicast

On Thu, 14 Mar 2002, Keith Moore wrote: > > Who wants an application that can work _only_ with IPv6? Nobody. > > strongly disagree. IPv6 provides capabilities that simply don't > exist in IPv4 - among them the ability to provide large numbers of > stable addresses. In other words, IPv6 enables

Last Call: Default Address Selection for IPv6 to Proposed Standard

The IESG has received a request from the IP Version 6 Working Group Working Group to consider Default Address Selection for IPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL P

RE: Securing Neighbor Discovery

[Sorry if this is not directly relevant to the list but it must be said...] > I think the design needs to accommodate both small networks and > large networks, i.e. it must be scalable. I think that can be > achieved by providing space to leverage off the existing > authentication => I

Re: Securing Neighbor Discovery

Hesham, > > I think the design needs to accommodate both small networks and > > large networks, i.e. it must be scalable. I think that can be > > achieved by providing space to leverage off the existing > > authentication > > => In fact, the most scalable solutions will be > achieved u

next steps for the cellular host draft

Based on the discussions on the mailing list, some off-line discussions and new developments, the authors of the cellular host draft would like to suggest a possible way forward in this area. Basically the suggestion is: - The IPv6 WG will work a generic IPv6 Node Requirements draft. Work t

Updated IPv6 working group agenda for Minneapolis IETF

The updated agenda is attached. The changes were to remove the zero time slot for the address selection draft because an IETF last call has been started and to move the second IPv6 Node Requirements talk to Thursday as was originally intended. Bob

TAHI Test Event Report is available

Hi all, We had held "The 3rd TAHI IPv6 Interoperability test event" in january. 27 organizations had participated in this event. The report of this event is already available. Visit here. http://www.tahi.org/presentation/3rd-interop/ Regards, . Hiroshi MIYATA @ TAHI Project -

Re: Securing Neighbor Discovery

>So, this is getting a little off topic for this list, perhaps >we should move the discussion elsewhere? I guess so. >I don't want to denigate the importance of SOHO and small >networks. Small networks are OK, but designing >something for the Internet based on an assumed small network >c

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

Hi Alexandru, 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. (I know that Francis has a draft out on this topic, and no I have not read it, yet.) For instance, when the 3GPP mechanism of address allocati

Request to Advance "Recommendations for IPv6 in 3GPP Standards"

Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename: dra

Re: TAHI Test Event Report is available

On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: > We had held "The 3rd TAHI IPv6 Interoperability test event" in january. > 27 organizations had participated in this event. > > The report of this event is already available. > Visit here. > http://www.tahi.org/presentation/3rd-interop/ Where are the r

Re: TAHI Test Event Report is available

Sorry we can not disclose the test results because of NDA. On 2002.03.15, at 16:18, Pekka Savola wrote: > On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: >> We had held "The 3rd TAHI IPv6 Interoperability test event" in january. >> 27 organizations had participated in this event. >> >> The report of