> On Mon, 04 Aug 2003 11:06:55 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
> I would like to hear from the working group on how we should proceed. I
> think the choices are:
I prefer this one:
> A) Deprecate Site-Local addresses independently from having an alternative
> solution a
> That's an interesting expectation. As co-author of the planned
> deprecation draft, I'd been assuming a more classical deprecation
> action, in which we would simply state the previous semantics of
> FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
> permanently assigned by IANA.
> On Tue, 5 Aug 2003, Keith Moore wrote:
> > > We already have alternatives
> > > to site-local addresses: 6to4 addresses based on PI or RFC1918
> > > IPv4 addresses.
> >
> > 6to4 addresses based on RFC 1918 addresses should be forbidden.
> > IMHO, this is an oversight in the 6to4 RFC.
>
> They
Ralph,
Thanks for the clarification. I think I misunderstood "not replace
site-local addresses in any form". If I have it right, the phrase implies
"explicitly do not consider any alternatives", to which I agree that
accepting indicates that the WG
is interested in considering alternatives.
Tha
> humm - it is not all that often that we have said that 2/3 is rough
> consensus in the IETF
note that the plurality was 3/4 not 2/3.
IETF IPng Working Group Mailing List
IPng Home Page: http://playgroun
Christian,
It is possible to write sufficient restrictions and avoid both the drift
towards announcing /48 in the DMZ and using the unique local addresses in
a NATv6 configuration. The requirement is that the site local replacement
be "special". We can for example request that backbone routers
> > That's an interesting expectation. As co-author of the planned
> > deprecation draft, I'd been assuming a more classical deprecation
> > action, in which we would simply state the previous semantics of
> > FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
> > permanently assigne
Interesting point.
Feel free to look up 192.102.91.0. It is being NAT'ed for a client of mine.
I've not convinced them yet to route it with a real firewall to their isp ;-(
--
Todd Fries .. [EMAIL PROTECTED]
Free Daemon Consulting, LLCLand: 405-748-4596
http://FreeDaemonCon
> We already have alternatives
> to site-local addresses: 6to4 addresses based on PI or RFC1918
> IPv4 addresses.
6to4 addresses based on RFC 1918 addresses should be forbidden.
IMHO, this is an oversight in the 6to4 RFC.
IETF
> The chances that SL addresses will simply be deprecated are something
> approaching zero.
SLs are a virus that must be eradicated at any cost.
the best available method is quarantine.
routers need to start filtering SLs by default.
apps need to refuse to use them.
DNS servers need to refuse to
Sorry; yes I have read that draft and plan to comment on it. My remarks
had to do with the "Choice A" approach of removing SLs without advancing
that draft (or something else) _at the same time_.
--On Tuesday, August 05, 2003 10:00 -0700 Fred Templin
<[EMAIL PROTECTED]> wrote:
Hans Kruse wrot
> What this means to me is that first we need to promulgate something
> along the lines of draft-baker-ipv6-renumber-procedure-00.txt. It
> needs some expanding to further automate the process. The more we
> automate the less pain the network manager will feel during a
> renumbering event.
I co
Brian E Carpenter wrote:
That's an interesting expectation. As co-author of the planned
deprecation draft, I'd been assuming a more classical deprecation
action, in which we would simply state the previous semantics of
FEC0::/10, state that the prefix SHOULD NOT be used, but leave it
permanently
Brian E Carpenter wrote:
Eliot,
That seems to me to be orthogonal. I agree that it would be good to see
renumbering support (maybe it's a v6ops item??). But that doesn't destroy
the value of Bob's proposal.
I guess my concern is that ISPs end up routing the address space in
Bob's proposal and th
This may be a nit -- but wouldn't it make more sense then to call you
preferred course of action "B", and publish 2002:RFC1918 as the (temporary)
replacement?
I guess I am suggesting that the WG pursue its work in such a way that we
do not create a vacuum; I feel strongly that the set of IPv6
The three options are really the same. We already have alternatives
to site-local addresses: 6to4 addresses based on PI or RFC1918
IPv4 addresses. We didn't have these alternatives a few
years ago. These aren't perfect, which is why we must develop
draft-hinden-ipv6-global-local-addr, but they'r
I vote for B from individual technical perspective.
C and A can only be agreed with politically.
- Original Message -
From: "Bob Hinden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, August 05, 2003 3:06 AM
Subject: Moving forward on Site-Local and Loca
Jeroen,
> Jeroen Massar wrote:
> At this moment you can announce almost anything
> you want apparently.
Yep I see /32 /33 /35 /40 /41 /42 /44 /48 /64 from some
peers, Including some interesting ones such as:
2001:530:DEAD:BEAD::/64
This is the very reason we have to be very careful with any kind
Ralph,
Furthermore, based on the record of the question from the minutes of the SF
meeting and the question put to the ipng mailing list, how was this
conclusion arrived at:
A fourth alternative is to not replace site-local addresses in any form,
but I think the working group has made it clear th
Bob,
I am sorry, but while it is a good attempt to come up with a happy
medium between SLs and global addresses, I disagree with the approach
that draft-hinden-ipv6-global-local-addr-02.txt takes. I would prefer
an approach that makes the stability of the IP address less important
rather than
Patrik Fältström wrote:
From an Application (above TCP) perspective, A, definitely A. Itojun
summarizes well the issues. Mandating a host to know topology is just
a really bad thing. Really really bad.
I concur with an added "really" tagged on.
-
21 matches
Mail list logo
