Whoops! I sent this before seeing the similar note from
Christian. Not meaning to belabor the point or otherwise
come down too hard on you, Eric. You are certainly not
the only one involved in these discussions who could
benefit from a read of the documents.
Fred
[EMAIL PROTECTED]
Fred Templin wrot
Eric,
EricLKlein wrote:
To be honest, as stated in another e-mail, I have not read the
draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and
will read it soon.
I'm a bit perplexed that you seem to have time to engage in
the e-mail discussions but have not yet found the time to
> ...prefer to say it the other way ... if your evidence is actual,
> it shows the other groups are disconnected with this one.
>
> I agree, but either way there is a disconnect.
Eric,
One simple way to cure the disconnect would be to actually read the
drafts that you are quoting, starting with
Mark Smith wrote
> > If there are this many new drafts coming out in November 2003, even with
a
> > WG decision to not do NAT IPv6 then there should be a big red flag that
> > there is a disconnect between what this WG says and what others are
doing.
> >
>
> I would prefer to say it the other way .
EricLKlein wrote:
>
> Christian Huitema wrote:
>
> > Andrew, the draft has provision for both "registered unique local
> > addresses" and "probably unique local addresses". The registered unique
> > addresses are not valid on the Internet, but they definitely will not
> > collide with other addre
On Mon, 24 Nov 2003 14:54:41 +0200
"EricLKlein" <[EMAIL PROTECTED]> wrote:
>
> Can you explain why are we allocating another range for locally assigned
> prefixes, rather than reusing the FEC8:; FEC9:: spaces that were used this
> way and are now going to stay unallocated? Why tie up a second r
On Mon, 24 Nov 2003 15:00:46 +0200
"EricLKlein" <[EMAIL PROTECTED]> wrote:
> Tim Chown wrote:
>
> > On Mon, Nov 24, 2003 at 10:03:44AM +0200, EricLKlein wrote:
> > >
>
> This may be true, but no one is proposing green cow become an IETF standard.
> The list I provided is recently proposed IETF d
Tim Chown wrote:
> On Mon, Nov 24, 2003 at 10:03:44AM +0200, EricLKlein wrote:
> >
> > The list of IPv6 plus NAT is over 140 documents long, with many of them
> > being proposed in the last 5 days. The look up list I ran is:
> >
http://search.ietf.org/cgi-bin/htsearch?config=htdig&restrict=http%3A
Brian Haberman wrote:
> I'm curious, have you read draft-ietf-ipv6-unique-local-addr-01.txt?
> The locally assigned prefixes come out of the FD00::/8 range and
> the centrally assigned prefixes come out of the FC00::/8 range. Can
> you explain to me why you think they will collide at some point?
>
EricLKlein wrote:
>
> Andrew White wrote
> > The problem with these people's arguments is that it's not the address
> range
> > that gives the security, it's the fact that you have an isolated network
> > connected to the global network via only a proxy (NAT) and firewall.
> >
> > You can use any
Mark Smith wrote
> > I am still have 2 concerns with these concepts:
> > 1. People do not want to register their secure internal network nodes
(bank
> > central computes etc) so the "registered unique local addreses" may not
meet
> > their needs. They do not want to have even theoritically reachabl
Eric,
EricLKlein wrote:
2. For the "approxiamtely" or "probably" unique local addresses I am
concerned that these addresses will eventually be assigned as part of the
registered addresses and can then be in conflict with "legitimate" nodes.
I'm curious, have you read draft-ietf-ipv6-unique-local-
On Mon, Nov 24, 2003 at 06:02:48PM +1030, Mark Smith wrote:
> Probably not going to happen in the next 200 years or more, and more
> likely it will never happen. By the time that becomes a possibility,
> IPv7
already proposed at least twice: TP/IX (RFC 1475) or CATNIP (RFC 1707)?
Regards,
On Mon, 24 Nov 2003 10:58:43 +0200
"EricLKlein" <[EMAIL PROTECTED]> wrote:
> Tim Chown wrote
> >
> > It is not unlikely that people will be lazy and just use fd00::/48 for
> sites,
> > and thus add back in great ambiguity to the probabilisticly unique address
> > space.
>
> First you ask a quest
On Mon, 24 Nov 2003 10:33:41 +0200
"EricLKlein" <[EMAIL PROTECTED]> wrote:
> > Mark Smith wrote
> > > I am still have 2 concerns with these concepts:
> > > 1. People do not want to register their secure internal network nodes
> (bank
> > > central computes etc) so the "registered unique local addr
Tim Chown wrote
>
> So they can use addresses from the probabilistically unique range under
> the space fd00::/8. There is, in terms of raw usage, no difference
between
> using fd00::/8 or fec0::/10. External networks would still have to route
> the prefixes back to you for you to be reachable,
On Mon, Nov 24, 2003 at 08:37:39AM +0200, EricLKlein wrote:
>
> I am still have 2 concerns with these concepts:
> 1. People do not want to register their secure internal network nodes (bank
> central computes etc) so the "registered unique local addreses" may not meet
> their needs. They do not wa
> Mark Smith wrote
> > I am still have 2 concerns with these concepts:
> > 1. People do not want to register their secure internal network nodes
(bank
> > central computes etc) so the "registered unique local addreses" may not
meet
> > their needs. They do not want to have even theoritically reacha
>
> Probably not going to happen in the next 200 years or more, and more
likely it will never happen. By the time that becomes a possibility,
IPv7 or IPv8 will be ready, with, based on the IPv4 32 bit -> Ipv6 128
bit trend, 512 bit addresses ... of course, every bit added doubles the
size of th
han a
> RFC1918 type of address space. The more I hear about these options the more
> I want to bring back site local addresses.
>
I suggest you have a read or review the following two IETF documents :
"RFC 2993 - Architectural Implications of NAT"
http://www.faqs.org/rfcs/
Christian Huitema wrote:
> Andrew, the draft has provision for both "registered unique local
> addresses" and "probably unique local addresses". The registered unique
> addresses are not valid on the Internet, but they definitely will not
> collide with other addresses.
I am still have 2 concerns
> > You can get verifiably unique addresses if you go through the
> > registration procedure. So, if you follow the good housekeeping
rules,
> > you should never encounter the bug you mention.
>
> Though I'd also ask: "Claim portions of WHAT network?" I'm talking
about
> *local* addresses, which
Christian Huitema wrote:
>
> > This would work, and would be acceptiable to most people if there was
> > a simple rule that worked, and would continue to work as the network
> > grows.
> > My concern is that an 'approximately unique' local address could at
> > some point become less than unique an
> This would work, and would be acceptiable to most people if there was
a
> simple rule that worked, and would continue to work as the network
grows.
> My
> concern is that an 'approximately unique' local address could at some
> point
> become less than unique and could cause routing problems when
Andrew White wrote
> The problem with these people's arguments is that it's not the address
range
> that gives the security, it's the fact that you have an isolated network
> connected to the global network via only a proxy (NAT) and firewall.
>
> You can use any address range you like inside the N
EricLKlein wrote:
> This is not the first time that I have heard that someone was willing to
> skip IPv6 because of the percieved pain and security threat that
> standards compliance would entail. But then again these are all people
> that take security and network administration very personal and
Eric,
Take your argument to the people opposing the Hain/Templin draft, because
your point is clearly made in that document.
Brian
EricLKlein wrote:
>
> Margaret.Wasserman wrote
> > > I have been speaking to different
> > > companies here in Israel, and the basic answer is that if I
> > > ca
On Wed, Nov 19, 2003 at 03:12:16PM +0200, EricLKlein wrote:
>
> This is not the first time that I have heard that someone was willing to
> skip IPv6 because of the percieved pain and security threat that standards
> compliance would entail. But then again these are all people that take
> security
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
| Hi Eric,
|
|
|>I have been speaking to different
|>companies here in Israel, and the basic answer is that if I
|>can not have site locals and NAT then I will not move to IPv6.
|
|
| If these people are happy with IPv4 NAT, why
Margaret.Wasserman wrote
> > I have been speaking to different
> > companies here in Israel, and the basic answer is that if I
> > can not have site locals and NAT then I will not move to IPv6.
> If these people are happy with IPv4 NAT, why would they want
> to move to IPv6? They couldn't need mo
Hi Eric,
> I have been speaking to different
> companies here in Israel, and the basic answer is that if I
> can not have site locals and NAT then I will not move to IPv6.
If these people are happy with IPv4 NAT, why would they want
to move to IPv6? They couldn't need more address space (net
Christian Huitema wrote:
> Frankly, I don't believe that we should worry about net 10 in the site
> local deprecation draft. The site local deprecation document is
> specifically about the prefix 0xFEC0::/10. In any case, such addresses
> are explicitly banned in the IPv6 addressing architecture. S
Frankly, I don't believe that we should worry about net 10 in the site
local deprecation draft. The site local deprecation document is
specifically about the prefix 0xFEC0::/10. In any case, such addresses
are explicitly banned in the IPv6 addressing architecture. Section 2.5.5
of RFC 3513 states:
> > While I'd personally love to declare RFC 1918 "Historic", it really
is
> > completely IPv4 specific so we have no reason to reference it.
>
> I would agree that RFC1918 is pure v4 issue, but we will need take
into
> account that when these IPv4 networks are connected as part of IPv6
> networks
documents include [RFC2772, RFC2894,
RFC3082, RFC3111, RFC3142, RFC3177].
Julian
>-Original Message-
>From: Christian Huitema [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 14, 2003 11:27 AM
>To: Bob Hinden; [EMAIL PROTECTED]
>Cc: Brian E Carpenter
>Subject: RE: SL depreca
Brian E Carpenter wrote:
> While I'd personally love to declare RFC 1918 "Historic", it really is
> completely IPv4 specific so we have no reason to reference it.
I would agree that RFC1918 is pure v4 issue, but we will need take into
account that when these IPv4 networks are connected as part of
Brian E Carpenter wrote:
> While I'd personally love to declare RFC 1918 "Historic", it really is
> completely IPv4 specific so we have no reason to reference it.
I would agree that RFC1918 is pure v4 issue, but we will need take into
account that when these IPv4 networks are connected as part of
While I'd personally love to declare RFC 1918 "Historic", it really is
completely IPv4 specific so we have no reason to reference it.
Where can I find the NATv6 group? I have a few things I'd like to
say to them...
Brian
EricLKlein wrote:
>
> I think the most basic RFC one was missed from t
I think the most basic RFC one was missed from the list: RFC1918. Especially
since the NATv6 group is probably working under the presumptions that these
addresses, or ones like them, still exist in IPv6.
IETF IPv6 working grou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Huitema wrote:
| So, what about a text such as:
|
| Several IETF documents mention site local addresses [RFC2772, RFC2894,
| RFC3082, RFC3111, RFC3142, RFC3177]. These mentions should be removed if
| and when these documents are updated. In pa
Thursday, November 13, 2003 3:34 PM
> To: [EMAIL PROTECTED]
> Cc: Brian E Carpenter; Christian Huitema
> Subject: Re: SL deprecation draft
>
> I personally don't think it is necessary to update most of these
> RFCs. Specifically:
>
> > > RFC2772, 6bone routing
Brian,
This deprecation will require substantive updates to the Address Architecture
and Default Address Selection documents [ref, ref].
The site local prefix is also mentioned in several other documents which need
at most minor editorial updates [ref, ref, ref...].
OK, as long as it is written su
On Fri, Nov 14, 2003 at 03:58:35AM +0100, Brian E Carpenter wrote:
>
> That isn't completely clear to me. We could say something like:
>
> This deprecation will require substantive updates to the Address Architecture
> and Default Address Selection documents [ref, ref].
>
> The site local prefi
Pekka Savola wrote:
>
> On Thu, 13 Nov 2003, Bob Hinden wrote:
> > So my take is that only the Address Architecture and Default Address
> > Selection documents need to be listed.
>
> FWIW, totally agree here. Listing those which had no issues of substance
> only confuse the reader.
That isn't c
On Fri, Nov 14, 2003 at 02:16:47AM +0100, Leif Johansson wrote:
>
> Can't we just notify the authors and let them decide?
I hope so. If we don't notify the authors they may not know to make
the site local update at any subsequent bis version...
Tim
---
On Thu, 13 Nov 2003, Bob Hinden wrote:
> So my take is that only the Address Architecture and Default Address
> Selection documents need to be listed.
FWIW, totally agree here. Listing those which had no issues of substance
only confuse the reader.
--
Pekka Savola "You each na
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
|> > RFC2894, router renumbering (an example contains FEC0)
|> > RFC3111, SLP (an example contains FEC0)
|> > RFC3142, TRT (an example contains FEC0)
|
|
| If it's only used in an example, then I don't think an update is
| required. If these documen
I personally don't think it is necessary to update most of these
RFCs. Specifically:
> RFC2772, 6bone routing practise
The 6bone is being turned off.
> RFC2894, router renumbering (an example contains FEC0)
> RFC3111, SLP (an example contains FEC0)
> RFC3142, TRT (an example contains FEC0)
If
IL PROTECTED] On Behalf Of
> Brian
> > E Carpenter
> > Sent: Thursday, November 13, 2003 12:43 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: SL deprecation draft
> >
> > Alain,
> >
> > Yes, you're correct that we should add that. There was a sli
By the way, does someone has a list of these RFC?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Brian
> E Carpenter
> Sent: Thursday, November 13, 2003 12:43 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SL deprecation draft
&g
Alain,
Yes, you're correct that we should add that. There was a slight lack of preparation
for the session between me and Christian so this was overlooked, but I
don't think it is contentious.
Brian
Tim Chown wrote:
>
> On Thu, Nov 13, 2003 at 10:47:35AM -0800, Alain Durand wrote:
> > I just
On Thu, Nov 13, 2003 at 10:47:35AM -0800, Alain Durand wrote:
> I just watched the video of the site local deprecation presentation
> from Christian Huitema.
> There is one issue raised in the mailing list that Christian did not
> mention,
> that is the current deprecation section does not mentio
I just watched the video of the site local deprecation presentation
from Christian Huitema.
There is one issue raised in the mailing list that Christian did not
mention,
that is the current deprecation section does not mention the list of
RFCs that are impacted.
I strongly object to the publica
53 matches
Mail list logo
