> On Thu, 17 Nov 2005 08:43:29 +0200 (EET),
> Pekka Savola <[EMAIL PROTECTED]> said:
>> Issue 1: Restrict operation of the protocol to link-local use.
>>
>> Resolution:
>> The consensus is to retain the more flexible multi-hop capability.
>> An additional sentence or two will be added to
On Wed, 16 Nov 2005, Brian Haberman wrote:
Issue 1: Restrict operation of the protocol to link-local use.
Resolution:
The consensus is to retain the more flexible multi-hop capability.
An additional sentence or two will be added to the Security
Considerations section recommending the
I agree. I think any allocation should be considered experimental,
particularly since there is a possibility that the identifiers might become
longer in the future. However, it is also possible that 128 bit identifiers
might become standard practice. At this point, we don't really know.
Pekka Nikander wrote:
Geoff, to quote my longer message
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05900.html,
"I fully agree with you that a new identifier name space should not be
mixed with any existing locator space." Hence, from what I called "an
ideal architectural point of
>
> Issue 3: Discovery of tunnel endpoints.
>
> Resolution:
> This change will be made and will be based on the text proposed
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html
I'm not sure this is such a good idea.
A) there are may kinds of tunnels, like IPv6/UDP/I
Brian Haberman wrote:
> Issue 3: Discovery of tunnel endpoints.
>
> Resolution:
> This change will be made and will be based on the text proposed
> http://www1.ietf.org/mail-archive/web/ipv6/current/msg05674.html
I missed out on the discussion of the above, but I do hope that there is
All,
As promised during the IPv6 WG session in Vancouver, this is
my attempt to resolve the open issues with the ICMP Name Lookup
draft. From my review of my e-mail and the mailing list archive, there
are three open issues on the table. I will list each and propose a
resolution to each.
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. Even a "killer application"
On Wednesday 16 November 2005 15:14, Francis Dupont wrote:
> Please note KHIs have other usages than HIP...
Off course! That was just an usefulness example of having identifiers
allocated out of the locator space as a transition tool: it makes
possible to use at the same time identifiers and loc
Please note KHIs have other usages than HIP...
Regards
[EMAIL PROTECTED]
PS: one of the strong points of the KHI drafts is it should cover
more than one usage (if possible all usages) for crypto generated
identifiers which look like addresses (so called "not routable
addresses") for the API.
--
On Tuesday 15 November 2005 23:42, Erik Nordmark wrote:
> Pekka Nikander wrote:
(...)
> > 2a. Implement KHIs on the top of SHIM6
> >- changes stack but minimally from 1a, perhaps not at all
> >- does not change applications
>
> I don't understand the last point. A KHI couldn't be used in
Hi,
I think I found a small typo in the draft: -
asymmetric reachability
- a link where non-reflexive and/or non-transitive
reachability is part of normal operation. (Non-
reflexive reachability means packets from A reach B
but packets from B don't re
12 matches
Mail list logo
