>3.0 IANA Considerations
>
> The following prefix is reserved for use in documentation and MUST
> NOT be assigned to any operational IPv6 nodes:
>
> 2000:0001::/32
>
>==> I do not understand why this reservation has been made; I see zero
>technical reason for it -- and it would prevent th
> C M Heard writes:
Mike> I saw that when I went through the archived e-mail. Do you
Mike> think that having an OCTET STRING-based policy selector (in
Mike> addition to destination prefix/prefix length and next hop) as I
Mike> suggested can provide the required flexibility? As far as I can
Hi Samita,
> In the last sentence, did you mean to say that the node should have a
> configuration knob whether to turn on privacy extension behavior ?
>
> If so, would it be clearer to say something like the following ?
>
> 'It is recommended that the node be configurable to turn on/off
> the
Bob Hinden wrote:
...
> >
> >I, for one, am very adamantly against reserving 2000:0001::/32. That
> >wastes a complete 2000::/16 (if, for some purposes, a whole /16 or first
> >parts of it are needed). An extremely bad idea, IMO. I'd recommend taking
> >something from 2001, like 2001:0001::/32 or
David Conrad wrote:
>
> Brian,
>
> On Wednesday, January 29, 2003, at 02:33 AM, Brian E Carpenter wrote:
> > If we achieve stable locators, this problem largely goes away,
> > but stable names in themselves are insufficient IMHO.
>
> The problem isn't the DNS, but the concept of 'stable locator
On Monday, February 3, 2003, at 05:28 AM, [EMAIL PROTECTED] wrote:
It should be something like that, but I think Alain was suggesting that
a node-based policy would not be sufficient. It should be at least
application based policy, since different applications will not
work with 3041 addresses.
I am posting this to both the IPv6 and MIB mailing lists to get the
benefit of both groups' feedback.
On our platform we support IP addresses that exist on multiple hosts but
are only owned (i.e., advertised to routers) by one of these hosts. They
exist on the other hosts as part of a worklo
On Monday, February 3, 2003, at 07:02 AM, Brian E Carpenter wrote:
Lets try to avoid a lengthily discussion on this. I think the w.g.
has
more pressing issues. If others have strong feeling on this, I am
happy to
change it. Or remove it.
It's clear we won't converge rapidly on a specific c
Patrick Grossetete just pointed out to me that there is already a prefix
allocated (by APNIC) for documentation. It is:
2001:0DB8::/32
For more details see:
http://www.apnic.org/info/faq/ipv6-documentation-prefix-faq.html#3
Since I don't think we need two, I will remove the one I proposed
Pekka Savola wrote:
>
> On Fri, 31 Jan 2003, Michel Py wrote:
> > > The specific format of global unicast address under the 2000::/3
> > > prefix is:
> > > | 3 | n bits | 61-n bits | 64 bits |
> > > +---++---++
Dan Lanciani wrote:
> "Tony Hain" <[EMAIL PROTECTED]> wrote:
>
> |Suspend disbelief for a moment, and consider a name
> resolution service
> |where the consumer edge widget was responsible for both tracking
> |topology changes, and updating a branch of the name tree to keep it
> |aligned. Said
David Conrad wrote:
> ...
> Assume at the end point an address consists of a 64 bit value stuffed
> into the lower 8 bytes of an IPv6 address with the upper 64 bits 0.
>
> The lower 64 bits of the destination would be put into an
> in-addr.arpa-like tree, mapping that end point into multiple AAA
Hi John,
> > If so, would it be clearer to say something like the following ?
> >
> > 'It is recommended that the node be configurable to turn on/off
> > the privacy extension for stateless address autoconfiguration, when
> > it is implemented.'
>
> It should be something like that, but I thi
"Tony Hain" <[EMAIL PROTECTED]> wrote:
|Dan Lanciani wrote:
|> "Tony Hain" <[EMAIL PROTECTED]> wrote:
|>
|> |Suspend disbelief for a moment, and consider a name
|> resolution service
|> |where the consumer edge widget was responsible for both tracking
|> |topology changes, and updating a branc
Dan Lanciani wrote:
> | ...
> |There is an important difference between pushing all the way
> to the end
> |system, vs. the edge router. While architecturally there is little
> |difference, when the mapping function is in the end system
> the level of
> |churn on the registration infrastructur
Alain,
All your points are valid, but I'd argue the node requirements
document is the wrong place to have this level of detail.
Instead, 3041 should be respun with more text about these issues. I
think Node requirements would be better off (in general) just pointing
to other basic documents and l
On Mon, 3 Feb 2003, Juergen Schoenwaelder wrote:
> Since forwarding architectures tend to look pretty different, I guess
> we can't do more than using some opaque identifier - whether that is
> an OBJECT IDENTIFIER, an INTEGER will some smart numbering scheme
> (similar to SnmpSecurityModel), or an
Hi all,
I will re-read 3041, craft some text, point to a relevant section
in 3041. I'll try to get this done today.
thanks,
John
> -Original Message-
> From: ext Thomas Narten [mailto:[EMAIL PROTECTED]]
> Sent: 04 February, 2003 05:12
> To: Alain Durand
> Cc: Loughney John (NRC/Helsinki
18 matches
Mail list logo
