Alain,
I'm not sure that 'leak" is really an issue here, nor do I see "risk of
incompetence of implementation" as really being an adequate justification
of an address allocation.
Let me put it in a relatively stark fashion: If they are truly
non-routeable identifiers then define an identity token space from the
start and use it - don't attempt to steal locators!
Geoff
At 10:12 AM 15/11/2005, Durand, Alain wrote:
Geoff,
The question is: can those identifier leak from an application and then be
used as locators?
If there is a risk of leak, there is a need for a separate prefix. If we
are 100% sure there is no way that any application would ever leak, then I
would agree we do not need to use a dedicated prefix.
- Alain.
-----Original Message-----
From: [EMAIL PROTECTED]
To: Manfredi, Albert E
CC: ipv6@ietf.org; Internet Area
Sent: Mon Nov 14 17:53:40 2005
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 PROTECTED]
> > Sent: Monday, November 14, 2005 3:11 PM
> > To: Pekka Nikander
> > Cc: ipv6@ietf.org; 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
>ipv6@ietf.org
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
----------------------------------------------------------------------------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
