ready for IETF
last call.
Bob Hinden / Margaret Wasserman
IPv6 Working Group Chairs
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
At 07:24 PM 8/30/2003 +0200, Wijnen, Bert (Bert) wrote:
Thanks for the MIB doctor review Mike.
Yes, thanks Mike for a very thorough job!
And thanks to the authors/editors to get this in
good shape. Sounds like we're getting real close to
IETF Last Call ??
Yup. Three of the IPv6 MIBs (TCP, IP and
[Dropped the IESG...]
At 11:39 AM 8/26/2003 +0200, Kurt Erik Lindqvist wrote:
Agreed. No replacement is also a replacement. That said, I think there is
a lot left to discuss on what to recommend for the cases that have been
brought up.
I agree. There are a number of situations (disconnected
or change it to ipv6 to be consistent with the current name
of the working group. Please let the chairs know if you have a strong
preference one way or the other.
More news later as the details get worked out.
Thanks,
Bob Hinden and Margaret Wasserman
IPv6 w.g. chairs
At 06:07 PM 8/5/2003 +0200, 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
At 05:25 PM 8/5/2003 +0200, Brian E Carpenter wrote:
I'll go for B, or perhaps A.9 (i.e. a version of B in which
we avoid recursive normative references between the two documents).
If your version A.9 existed, I would have chosen it...
I don't much care for the idea of gratuitous normative
Hi Michel,
At 12:09 PM 8/12/2003 -0700, Michel Py wrote:
- Whatever we can say about it, the network administrator gets to pick
what becomes of the Hinden/Haberman draft, globally routable PI _or_
private address. The prefix can't serve both purposes at the same time
for reasons explained 20
Just FYI --
I will be on vacation for the next two weeks, from
Saturday, August 16th through Monday, September 1st.
I will be reading mail occasionally during my vacation,
to deal with critical issues. However, I probably
won't keep up-to-date on the WG mailing list.
Margaret
Hi All,
Last week was a very busy week on the IPv6 mailing list, with
well over 300 messages. I've included the statistics below.
At this volume, it is very likely that many IPv6 mailing list
members are failing to keep up with the list. If you appear
as a frequent poster in the list below,
At 10:26 AM 8/7/2003 -0700, Tony Hain wrote:
Right now I cannot find a single application where locally scoped
addresses give
me anything worth the effort. Those are my 5 cents - since
you asked for
details :-)
Wait, you started off by saying that you really need to filter and keep some
I prefer option (B), but I would find option (A) acceptable.
Margaret
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
Hi Ralph,
At 11:01 PM 8/4/2003 -0400, Ralph Droms wrote:
Bob's e-mail to the ipng mailing list used to judge WG consensus on
deprecating site-local addresses asked:
The question is:
Should we deprecate IPv6 site-local unicast addressing?
Valid responses are:
YES -- Deprecate
[Note: This message is being sent in my role as an IPv6 WG chair.
I have already recused myself from IESG consideration of Tony
Hain's appeal and will not participate in this discussion as an
Internet AD.]
Hi Robert,
I'd like to respond to a few of the things that you mentioned in
your
Hi Bhaskar,
This document has not yet been published... Christian Huitema
and Brian Carpenter have agreed to write it, and Christian
did discuss its proposed contents in Vienna. We are hoping
that a first draft will be available soon.
Margaret
At 04:55 PM 7/28/2003 -0400, Bhaskar S wrote:
Hi
At 10:39 AM 7/16/2003 -0400, Keith Moore wrote:
Lately I find myself wondering if there's not room for a uniform layer 2.5
interface that is designed to work over a set of bridged 802-style layer 2
networks, but presents a slightly different interface to the host. So for
instance hosts would be
list, and minor
editorial comments to the authors. This last call period will end on 16
July 2003.
Bob Hinden / Margaret Wasserman
IETF IPng Working Group Mailing List
IPng Home Page: http
-ietf-ipv6-rfc2011-update-03.txt
Pages : 114
Date: 2003-7-2
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the author. This last call period will end on 16
July 2003.
Bob Hinden / Margaret Wasserman
: draft-ietf-ipv6-rfc2012-update-03.txt
Pages : 25
Date: 2003-6-26
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end on 16
July 2003.
Bob Hinden / Margaret Wasserman
Date: 2003-6-30
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end on 15
July 2003.
Bob Hinden / Margaret Wasserman
IETF
At 12:46 PM 6/19/2003 -0400, Thomas Narten wrote:
Is this OK with everyone?
If so, we either need to reissue the document or ask for an RFC editor
note. I can go either way.
If it is okay with everyone, let's just re-issue the document.
I think that would be cleaner.
Margaret
At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote:
I still have a small preference preference for using FC00::/7 for the
globally unique local addresses due to the larger global ID, instead of
reusing the FEC0::/10 prefix. But either would work.
The problem with using FECO::/10 for these addresses
of requirements?
Margaret
At 11:02 AM 6/7/2003 -0400, Margaret Wasserman wrote:
At 03:46 PM 6/6/2003 -0700, Bob Hinden wrote:
I still have a small preference preference for using FC00::/7 for the
globally unique local addresses due to the larger global ID, instead of
reusing the FEC0::/10 prefix
Hi Mika,
At 02:21 PM 4/5/2003 +0300, Mika Liljeberg wrote:
On Sat, 2003-04-05 at 13:11, Patrik Fältström wrote:
Yes, of course we should. But, I think we can not get real force behind
such work before we _first_ agree Site Local is not solving this
problem, and we therefore agree Site Local
Hi David,
At 05:05 PM 4/4/2003 -0600, David Borman wrote:
Well, if I am allowed to, I am now changing my vote to:
YES -- Deprecate site-local unicast addressing.
Yes, you are allowed to change your opinion and we will
consider your new position in our consensus determination.
The primary
Tony,
So even though the routing research group has not come up with a
solution that simultaneously addresses all three of these in the last 10
years of focused work, the IPv6 WG will promise to come up with a
solution quickly if we just deprecate the only viable approach we know
of first. I
Hi Dan,
Please help me to understand something. I have been trying to get people to
look at the portable identifier/routing problem for _years_.
Various people _have_ been looking at this problem for years. In fact,
the IPv6 WG toyed with it for a while in the mid-1990s. I agree that
this is
That may be what you want, but that is not what you have been saying. You
are advocating taking away private address space.
What private address space do you think that these people have now
that we are advocating taking away?
The site-local prefix is defined in the addressing architecture,
but
Hi Michel,
At 04:39 PM 4/3/2003 -0800, Michel Py wrote:
Unfortunately this requires people that are for IPv6 and not against and
that are willing to compromise. I regret to report that at this point I
count only three: Bob Hinden, you and me.
I find this statement highly offensive, and I
Hi Christian,
At 03:53 PM 4/4/2003 +0200, Christian Schild (JOIN Project Team) wrote:
I think it would be enough to come up with a BCP how to subdivide bits
11-48 in an intelligent way to prevent above. There were lots of ideas how
this could be done on this list.
We do need to define some
DO NOT DISCUSS THINGS IN THIS THREAD! (-- yelling :-)).
Please change the subject.
Thanks,
Margaret
At 01:56 PM 4/4/2003 -0800, Eliot Lear wrote:
Bill, I think what your missing is that to many of us, IPv6's selling
points sum up to the following two things (the others pale):
1. Large
Hi Michel,
Sorry for the delay in responding. Bob is in Beijing without good
mail access, and I have been out of the office the past couple of
days for personal reasons.
At 02:21 PM 4/1/2003 -0800, Michel Py wrote:
What is this consensus about? I was hoping that the mailing list would
be asked
I have a few thoughts to share on site-local addressing...
Many people have written to the list lately stating that site-locals
should be retained for (at least) one of these two reasons:
- Numbering for disconnected networks.
- Access control.
- Numbering for
Hi Jinmei,
At 02:36 PM 4/2/2003 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
What was the consensus, if any, on alternatives to site-locals when SL
is deprecated? In particular, which prefixes will we use for
disconnected or intermittently connected sites? I've checked
Hi John,
What is the amount of work to depreciate site locals - how many RFCs need
to be updated? I'm not convinced that deprecating site locals really solves
anything.
The work to keep, and finish, site-locals is much greater than
the work to deprecate them.
To deprecate them, I think that the
If you use this method to generate unique local addresses (which
may be one viable alternative), you still won't want the semantics
of current site-local addressing...
The current site-local architecture does not allow sites to overlap
or be nested. Sites also need to be convex which requires
Hi Michel,
No one is planning to change anything in the last 24 hours...
The current addressing architecture has been approved for publication
at PS, and it will be published at PS (barring unforseen circumstances).
We are currently discussing what the IPv6 working group wants to do
in future
On a side note, I just re-read addrarch 3.11 and I found no text about
how a WG deprecates a prefix. As far as I'm concerned, it could mean
that all WG members are supposed to telnet to all IPv6 routers in the
world and deprecate the prefix there. We need better than this.
The great thing about
While I think it would be great to design a mechanism that would
allow smooth operation of intermittently connected nodes whose
global addressing potentially changes at each re-connect, I do
not believe that we want to impose a costly and complex solution
on _all_ IPv6 nodes so that a few of them
Hi Tony,
At 10:23 AM 4/3/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
...
Access control is also useful, and a simple form of access
control will be needed in IPv6. However, site-local
addresses are a poor form of access control for two reasons:
- Site-local boundaries need
Why don't you simply make this a requirement? I have heard many times
that issue about the convexity although I don't remember opposition to
coupling the site boundaries with the AS or routing area.
We probably would have... Except that around the time that we actually
formulated the correct
Patrik Fältström sent this message to the IPv6 list many hours ago,
but it hasn't appeared on the list. I told him that I would resend
it for him, so here it is...
Margaret
From: Patrik Fältström [EMAIL PROTECTED]
Date: tor apr 3, 2003 15:25:51 Europe/Stockholm
To: [EMAIL PROTECTED]
Subject:
I realize that there
have been suggestions recently that you should always use a global address if
one is available, but that's not a problem with scoped addressing--it's a
way to deliberately break scoped addressing.
It is also a way to avoid breaking Mobile IP. And, it is a way to
avoid losing
Who said that they need to be globally routable? If the purpose
is for private addressing, there is no need to route them.
Margaret
At 10:17 PM 4/3/2003 -0500, Scott Bradner wrote:
better to have your own globally-unique, provider-independent
prefix (perhaps assigned by a registry)
I do not
What I'd really like to see is site locals left in the spec,
but issue a recommendation that they be avoided, by both developers and
users, until their use is better understood.
This is actually a pretty good match for deprecation by
my definition. We'd keep the prefix in the spec, but mark
it
you can skip this message; in any case you MUST NOT respond to
this query.
By now, all of you have heard about the IPv6 meeting held on
Thursday, March 20th, where we discussed what to do about
IPv6 site-local addressing.
At the meeting, the chairs (Bob Hinden and Margaret Wasserman)
changed
Does expressed an opinion mean stepped to the mike and
spoke or raised your hand during the consensus determination
at the meeting?
The latter. Do not respond to this consensus call if you
already raised your hand at the meeting in SF. People who
spoke at the mike, but did not express an
Hi Jeroen,
In IPv6 every enduser should have enough IP's simply
because of the simple rule [...]
Nevertheless customers should never have any need whatsoever for NAT.
If there once is a need for it IPv6 'failed' as it didn't get up to
the primary need for IPv6: More addressspace so that
Hi Siva,
During our 3GPP-related work last year, there were several comments
that indicated that the wording of the PPPv6 spec is somewhat
unclear. In particular, it seems to indicate the the address that
is negotiated via PPP will be the only address in use on the
client end of the PPP
The IPv6 Node Requirements is intended to document the minimal requirements
for an IPv6 node, and a DNS resolver is not one of those requirements.
You can have a perfectly-compliant IPv6 node that doesn't include any
DNS support.
If we start down the road of saying:
A node MUST include a DNS
Hi Jeroen,
These enterprises apparently don't want/require/need global
reachability for their hosts. Otherwise they would not NAT.
That depends on what you mean by global reachability.
I am writing to you from behind a NAT right now. From here,
I can reach web sites on the global Internet, etc.
Hi Eric,
Site-locals was voted down in the WG meeting in SF.
How do those of us who can not attend these conferences get into these
limited participation votes? I for one can not make frequent international
trips for a non-customer related meeting.
Two points of clarification:
(1) We
There are significantly more people on this list than you could fit in
one of the rooms in SF. The chairs need to raise the question on the
list, because this is not a trival issue. From reports I heard the whole
SF discussion was based on a bogus assertion that SL == NAT.
The chairs WILL raise
FYI --
Margaret
Date: Wed, 19 Mar 2003 04:01:09 +0100
From: Leif Johansson [EMAIL PROTECTED]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
To: [EMAIL PROTECTED], [EMAIL PROTECTED], Keith Moore [EMAIL PROTECTED],
Margaret
Hi Jinmei,
Thank you for your detailed feedback.
A few questions about your response... I'll try to respond
to the more substantive points later.
3.1.2.1 Problems for All Site-Border Nodes
Some people have commented that the same problems exist for link-
local addresses, but this is
Hi All,
Attached please find the final IPv6 WG agenda for IETF 56.
Margaret
---
IPv6 Working Group (ipv6) Agenda
IETF 56, San Francisco
CHAIRS:
Bob Hinden [EMAIL PROTECTED]
Margaret Wasserman [EMAIL PROTECTED]
First Session: Monday, March 17, 2003, 1930-2200
FYI --
A discussion on v6ops that really ought to be happening here,
since it concerns the ND RFC.
Margaret
To: Ronald van der Pol [EMAIL PROTECTED]
cc: Alain Durand [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
From: Sebastien Roy [EMAIL PROTECTED]
Subject: Re: dual stack IPv6 on by
Hi Pekka,
- Complete work on Scoped Addressing Architecture and publish.
== this will probably stay in limbo until some closure is reached about
site-local addressing, so putting it in a charter (as it depends on the
site-local course) may be a bit premature -- but ok if not too many cycles
are
Global Unicast
Address Format. RFC2374 will become historic.
Margaret Wasserman
IPv6 Working Group co-chair
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
Attached is a copy of the charter we sent to the Internet ADs.
Bob Hinden Margaret Wasserman
Internet Protocol Version 6 (IPv6) Working Group Charter -- DRAFT
Chairs:
Bob Hinden [EMAIL PROTECTED]
Margaret Wasserman [EMAIL PROTECTED]
Description of the Working Group:
The IPv6 working group
working
group last call is desirable to verify the consensus before forwarding the
document to the IESG.
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end on 11
March 2003.
Bob Hinden / Margaret Wasserman
to the authors. This last call period will end two
weeks from today on March 17, 2003.
Margaret Wasserman / Bob Hinden
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP
documents and last to status
reports.
Thanks,
Bob Hinden and Margaret Wasserman
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
Thomas, Erik,
The chairs belive that based on the email on the mailing list there is a
consensus in the IPv6 working group to publish the IPv6 Addressing
Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) as a Proposed Standard
as recommended below.
Bob Hinden and Margaret Wasserman
IPv6
Do you have a suggestion of somebody who could tell me if an
IPv6 router
is required to perform host discovery for host routes?
I'm sorry, but I don't completely understand the question...
If a router has a host route in its routing table, it doesn't
need to do any checking on that validity
Author(s) : M. Blanchet
Filename: draft-ietf-ipv6-ipaddressassign-06.txt
Pages : 8
Date: 2003-1-6
A working group last call for this document was completed on January 30,
2003.
Bob Hinden / Margaret Wasserman
IPv6 Working Group Chairs
Thanks,
Margaret
To: Bob Hinden Margaret Wasserman [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: IPv6 w.g. Last Call on A Flexible Method for Managing the
Assignment of Bytes of an IPv6 Address Block
On Thu, 16 Jan 2003, Bob Hinden Margaret Wasserman wrote:
This is a IPv6 working
send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end two
weeks from today on February 21, 2003.
Margaret Wasserman / Bob Hinden
IETF IPng Working Group
Sorry, I mistyped on or the other of the two revision dates...
The inetCidrRouteNextHopType is needed, because the two IP addresses
may not be the same type. Although they both have to be the same
IP version (v4 or v6), they may have different IPv6 scopes (i.e.
one could be global and one
Hi Brian,
When 8+8 first appeared, I was delighted and referred to it as
architected NAT. I think that is what we need, either in the form
of 8+8/GSE, map-and-encap, MHAP, or something like those. To me
that is by far the most hopeful class of solutions.
I agree. There are some potential
There seem to be at least a couple of possible PI schemes that are being or
have been kicked around in the past. Dan referenced a solution that he has
worked on and Tony Hain's geographic scheme, while currently targetted at the
multi-homing problem, might well offer a solution. If we are
This is the semantics police speaking:
PI = Does *NOT* scale.
Starting with this assumption leads us to two bad choices. Maybe it
is time to question this assumption?
Same here. I did not comment on this before, but I think that what
Margaret really means here is:
This is the crux of
But the problem remains as hard as it was in 1992. We don't know how
to aggregate routes for such addresses, and we don't know how to scale
the routing system without aggregation. Solve either of those
problems and you're done.
Maybe we can't solve this problem
If not, then we won't have
Hi Tim,
Not to pick on you... You are making some excellent points, and I
want to make sure I understand them.
And, I have serious doubts that
they will ever scale. But, if that is the case and we are going to be
forbidden from seeking other solutions that involve site-local addressing and
This is not the way PI is being understood in the realm that deals
with them, the RIRs. PI does not only mean portability, it also means
the routing mechanism that is (and always has been) in use, which is to
announce the prefix in the global routing table, making it grow.
No matter what
What term should I use for that?
Aggregatable PI addresses, which is however kind of a contradiction in
terms. Addresses are as much aggregatable as their assignment reflects
the underlying topology, which includes the split of the network among
various providers. By definition, a structure
On Wed, Jan 22, 2003 at 03:34:19 +0100, Erik Nordmark wrote:
Granted that this is a hard problem, but we seem to be spending emails
on multiple subsets of this problem (in different WGs) thus I think it
would be worth-while to concentrate thinking on the identifier/locator
separation
I think, but I'm not sure, that this assumes that we will have a scalable PI
scheme some time in the future (presumably by separating PI identifiers
from PA locators).
Actually, this is quite tricky...
If we _don't_ allocate PI addresses soon, enterprises will demand
IPv6 NAT to allow them to
Why would you expect an ISP to give up this revenue stream?
Your theory that the ISP's cost advantage in limiting the number and
stability
of addresses is solely (or even mostly) a result of scarcity is not consistent
with the ISP industry as it currently exists.
|We aren't here to provide
Hi Digamar,
Sorry for not replying earlier.
I have read the RFC reagrding the addressing in IPv6 and I understood that
Web servers , routers , load balancers, Gateways and Switches can have
either Unicast or Multicast or Anycast address.
Any IPv6 node can have any of these types of
Oops...
I made a mistake in the response. An anycast address can only
be assigned to a router (an IPv6 node that forwards packets), not
to a host.
So, most Web Servers could not be assigned an anycast address.
Sorry,
Margaret
At 08:28 AM 1/22/2003 -0500, Margaret Wasserman wrote:
Hi
Hi Mario,
The new addressing architecture has been approved for publication
as a Draft Standard, and should be published shortly. So, the
FECO::/10 is official.
Margaret
At 01:58 PM 1/16/2003 +0100, Mario Goebbels wrote:
Hi!
I think my question is best answered in this mailing list. When I
-06.txt
Pages : 8
Date : 2003-1-6
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will on January
30, 2003.
Bob Hinden / Margaret Wasserman
IETF
Hi Keshava,
DAD is intended to cover all unicast addresses (all scopes).
It includes an optimization, however, that allows nodes that
have checked a link-local address with a particular
Interface ID (IID) to skip checking other addresses that
are constructed on the same interface using that
Hiroki Ishibashi [EMAIL PROTECTED] wrote:
I am in favor of this document for site-local usages.
This document appropriately limits the use of site-local addresses,
and still leaves the room for future usage of them (which we don't know).
This comment raises a basic question regarding what
Hi Hiroki,
I know that you are writing for the Limited usage, but your document
does not leave the possibility of the Moderate usage at all.
Right. The recommendation in my document is for the limited usage.
Bob Hinden has written a draft that documents the moderate usage.
The WG will have
bottom line: the Atlanta poll was essentially meaningless except
to indicate that there's a significant fraction of the group
that wants to discourage SLs to some extent.
Based on the minutes, we agreed at the time that the poll did
not demonstrate rough consensus of those present to pursue
On each process, all routing information, including global and
site-local are handled. Because of this, a user need to redistribute
global prefixes (not site-local prefixes) each other.
This is the demerit of separating OSPF process per site.
Thanks, Hiroki. I think I understand...
Do you
Hi Ari,
The IETF does not, typically, specify algorithms.
There has been quite a bit of research done in efficient
FIB storage algorithms in other fora, such as the ACM,
though. Last time I looked into this topic (a couple
of years ago), trie-based algorithms were very popular,
and the Luleå
Hi Hiroki,
Yes, our SBR routers have been shipped since September, 2000 as
a commercial IPv4/IPv6 dual router. It supports RIPng, OSPFv3, and
BGP4+. I have explained our SBR support and routing protocols in this
mailing list once before when the site-local issues were brought up.
I do
Hi Keshava,
At 09:24 PM 12/22/2002 +0800, Keshava Ayanur wrote:
Hi,
Can I get more information IPV6 FIB?
Other than 3 fibs (link,site,global) do we need to have anything
for multicast .
There is no need to have a link-local FIB, as packets to/from link-local
addresses
Hi Hiroki,
Please let me verify two things on draft-wasserman-ipv6-sl-impact-00.txt.
1. Does $B!V(BThe Impact of Site-Local Addressing in IPv6$B!W(Btry to
prohibit the use of SBR completely?
If the WG chooses to follow the recommendations in this document,
then SBRs will not longer be
FYI --
Margaret
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The Impact of Site-Local Addressing in IPv6
Author(s) : M. Wasserman
Filename: draft-wasserman-ipv6-sl-impact-00.txt
Pages
Hi Ari,
At 12:58 PM 12/13/2002 +, aridaman kaushik wrote:
Hi all,
I am novice to Ipv6. I have doubts regarding tunnelling.
1. What is meaning of enabling/disabling of tunneling. Is it means
ceartion and deletion of tunnels.
I am not sure of the context in which you are asking the
Hi Digambar,
At 04:53 PM 12/11/2002 +0530, Digambar Rasal wrote:
We usually specify Ipv4 subnet like 255.255.255.0 or /8 so . But in Ipv6
while mentioning address we specify it /64 or /48 .
As you may already know, a subnet mask of 255.255.255.0 is actually
a /24. This means that the first
Hi James,
At 10:21 AM 12/11/2002 -0800, James Kempf wrote:
I'm in the process of upgrading my home computing infrastructure in order
to be
able to use IPv6.
Great!
Does anybody know a retail ISP in the US that provides IPv6
service (specifically, in the SF Bay Area)?
Unfortunately, I
I had proposed limiting the use of site-locals to completely isolated
networks (i.e. test networks and/or networks that will never be
connected to other networks). This would give administrators of
those networks an address space to use (FECO::/10) for those networks
The first question that
You where not at the rebellion/ad-hoc/let's get out of here and go for bee
multi6 meeting on Thursday in Atlanta.
I was not actually aware of these meetings until later... I have
since joined the mailing list.
One thing I have been think of. Do we know what the increased
prefix-length
Hi Tony,
At 05:44 PM 12/6/2002 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
It is my personal opinion that we should leave site-local
addresses as-is and strictly limit their use to completely
disconnected, isolated networks.
1) It is not possible for the IETF to restrict their use
At 09:51 PM 12/4/2002 -0800, Michel Py wrote:
IPv6 folk,
I tried to summarize below the GUSL / GUPI deal.
We are pursuing two tracks here:
I am not sure that we have general agreement that there should be
two courses. I, for one, do not think that we should create two
different types of
No. But I fail to see what we gain with creating a special block from
where we assign PI addresses. The RIRs can equally well assign PI space
from the current IPv6 unicast space. Sure, this will lead to growth in the
size of the DFZ, but that is a routing problem.
I think we're arguing the
1 - 100 of 292 matches
Mail list logo
