Subject: RE: [Int-area] Re: KHIs and SHA-256

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 Nov 2005 16:25:29 -0800

The purpose of the request identifiers is to be "network like", in the
sense that they are used by applications in place of addresses. They
share many of the attributes of addresses, e.g. size, binary format,
uniqueness. There is a natural trend that such "overlay identifiers" end
up being used directly for routing purpose. Hey, IPv4 addresses started
life as overlay identifiers...

-----Original Message-----
From: Geoff Huston [mailto:[email-masked]] 
Sent: Monday, November 14, 2005 4:15 PM
To: Christian Huitema; Manfredi, Albert E
Cc: Internet Area; [email-masked]
Subject: RE: [Int-area] Re: KHIs and SHA-256 

At 11:02 AM 15/11/2005, Christian Huitema wrote:
>IMHO, every identifier ends up being routed, at least in some context.

Does your statement here specifically encompass the DNS? If not, then
what 
is the difference between such DNS identifiers and the ones under 
consideration in this context?

regards,

   Geoff

>For example, there is a good case that on a disconnected ad hoc
network,
>it makes more sense to use the identifiers you have than to create some
>new addresses. Indeed, if one is willing to have individual host
entries
>in a routing table, then one can use any identifier.
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Geoff Huston
>Sent: Monday, November 14, 2005 3:40 PM
>To: Manfredi, Albert E
>Cc: [email-masked]; Internet Area
>Subject: RE: [Int-area] Re: KHIs and SHA-256
>
>I heard "non-routeable" with respect to these identifiers.
>
>Is this _really_ the case?
>
>    Geoff
>
>
>At 10:03 AM 15/11/2005, Manfredi, Albert E wrote:
> >I didn't assume that the identifier space with no locator overtones
>must
> >be non-intersecting with a routable network space.
> >
> >Are you saying that use of these identifiers must only apply to
>isolated
> >nets?
> >
> >Bert
> >
> >
> > > -----Original Message-----
> > > From: Geoff Huston [mailto:[email-masked]]
> > > Sent: Monday, November 14, 2005 5:54 PM
> > > To: Manfredi, Albert E
> > > Cc: Internet Area; [email-masked]
> > > Subject: RE: [Int-area] Re: KHIs and SHA-256
> > >
> > > Don't present such packets to the router.
> > >
> > > i.e. if you are working in an identifier space that has no locator
> > > overtones (I have already seen the assertion that these
> > > identifiers are
> > > "non-routeable"), then how exactly will these identity values
> > > show up in a
> > > packet on the wire and be presented to routers are a
> > > destination or source
> > > locator?
> > >
> > >    Geoff
> > >
> > >
> > >
> > >
> > >
> > >
> > > At 08:03 AM 15/11/2005, Manfredi, Albert E wrote:
> > > >Geoff,
> > > >
> > > >How would a router know not to forward such packets, in the event
>the
> > > >top 64 bits clash with a real IPv6 address?
> > > >
> > > >Bert
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Geoff Huston [mailto:[email-masked]]
> > > > > Sent: Monday, November 14, 2005 3:11 PM
> > > > > To: Pekka Nikander
> > > > > Cc: [email-masked]; Brian Haberman; Internet Area
> > > > > Subject: Re: [Int-area] Re: KHIs and SHA-256
> > > > >
> > > > > But nothing in what you have said is inconsistent with the
> > > > > proposition that
> > > > > there is _no_ requirement to allocate IPv6 unicast address
> > > > > space for this
> > > > > form of use of 128 numbers.
> > > > >
> > > > > As you yourself point out "they are non-routeable" and theya
> > > > > re understood
> > > > > to be "semantically different".
> > > > >
> > > > > i.e. what you are going with the number in this context is
>really
> > > > > interesting, and a Good Thing in terms of furthering our
> > > > > understanding of
> > > > > the implications of the identifier / locator split. But I
> > > > > have yet to see a
> > > > > justification as to why these numbers should also entail a
> > > > > reservation in
> > > > > the IPv6 unicast number space. Indeed, I can think of
> > > some tolerable
> > > > > arguments as to why they should deliberately clash with
> > > > > unicast address values.
> > > > >
> > > > > regards,
> > > > >
> > > > >       Geoff
> > > >
> > > >
> > >
> >--------------------------------------------------------------------
> > > >IETF IPv6 working group mailing list
> > > >[email-masked]
> > > >Administrative Requests:
>https://www1.ietf.org/mailman/listinfo/ipv6
> > >
> >--------------------------------------------------------------------
> > >
> > >
> > >
> > >
>
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 15 Nov 2005 16:03:51 -0500

Pekka Nikander wrote:

> As I wrote, I can't see how we could convince the world from going  
> from where we are now to a world that requires people to 
> change their  
> network stack, add a new piece of infrastructure, and to change  
> applications at the same time.  That won't happen, any more.

This is also my confusion in the thread.

I thought the I-D wanted to retain the 128-bit structure, but change the
semantics, specifically so as not to require changes in the IP stack.

> Doesn't that transition strategy make any sense to you?  What is  
> wrong with it?
> 
> If you are worried that once established such hook for an identifier  
> space within the address space is likely to last for a long time,  
> please say so.
> 
> --Pekka

Bert