Moving the mailing list to ipv6@ietf.org

[Bob Hinden]

The new list ([EMAIL PROTECTED]) is set up and the mass subscription of all of 
the current subscribers to the ipng list will be starting shortly.  You 
should receive a "Welcome to the ipv6 mailing list" email announcing your 
subscription to the new list.

When the subscription process is done, I will send another email and at 
this point please start sending traffic to the new list.  I will 
redistribute any email sent to the old list after this point.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Update on Moving the IPng List

[Bob Hinden]

As was announced in late August the ipng list will be moved to 
ietf.org.  The list will be renamed:

  [EMAIL PROTECTED]

The new name is consistent with the current name of the working 
group.  Everyone who sent feedback on the name change supported this.

Everyone currently subscribed to [EMAIL PROTECTED] will be 
automatically subscribed to the new list.  You will not have to subscribe 
to the new list if you are currently subscribed to the old one.

The plan is to make the change tomorrow.  Everyone currently subscribed 
will receive a subscription message announcing the new list.  Announcements 
will also be sent to the old list before it is disabled and to the new list.

We also wanted to thank every one who volunteered to help manage the 
list.  We received more responses that were needed.  You will hear back 
directly with more information in a day or two.

Thanks,

Bob Hinden and Margaret Wasserman
IPv6 w.g. chairs

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Request to Advance "IP Forwarding Table MIB"

[Bob Hinden & Margaret Wasserman]

Thomas, Margaret,

The chairs of the IPv6 working group, on behalf of the working group, 
request that the following document be published as a Proposed Standard:

Title   : IP Forwarding Table MIB
Author(s)   : M. Wasserman, B. Haberman
Filename: draft-ietf-ipv6-rfc2096-update-05.txt
Pages   : 34
Date: 2003-8-29
A working group last call for this document was completed on 16 July 
2003.  This draft resolves issues raised during the last call.  This draft 
was reviewed by a "MIB Doctor" on 30 August 2003 and deemed 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://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Vacation

[Bob Hinden]

FYI, I will be on vacation starting tomorrow through September 5th.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Current Results from Poll

[Bob Hinden]

The current results of the poll (appended below) started early in August are:

Preference A   21
Preference B   13
Preference C7
--
Total  41
If you missed this and want to express a preference, please do so.  41 
isn't a large number given the size of the working group.  The chairs 
wanted to give folks who might have missed this due to being on vacation or 
who were overwhelmed by the amount of email a chance to respond.  You can 
send your responses directly to the chairs or to the list. We plan to send 
a final summary (including the actual results to make sure we got them 
correctly) in a few weeks.

Thanks,
Bob
Date: Mon, 04 Aug 2003 11:06:55 -0700
To: [EMAIL PROTECTED]
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Moving forward on Site-Local and Local Addressing
Cc: [EMAIL PROTECTED]
[IPv6 working group chair hat on]

I think the working group has been making good progress on replacing 
site-local addresses and wanted to get feed back from the working group on 
how we should move forward.  This is not intended to directly relate to 
the ongoing appeal of the working groups decision to deprecate the usage 
site-local addresses, but to get feedback on how to proceed.  I think it 
is very important that we move forward on this issue and not rehash what 
has happened in the past.

We now have a combined local addressing requirements document 
, a specific alternative to 
site-local addresses draft  
(accepted as a working group item at the Vienna IETF), and will soon have 
a draft describing why site-local addresses are being deprecated and doing 
the formal deprecation (authors identified and outline discussed at the 
Vienna IETF).  Note that all of these documents will proceed through the 
normal working group and IETF processes of last calls and review.

I think legitimate questions have been raised about how the working group 
should go about deprecating site-local addresses given their maturity in 
the current specifications and use in deployed products.  Specifically 
should they be deprecated independently from having an alternative 
solution available, at the same time an alternative is available, or 
sometime after an alternative is available.  A forth alternative is to not 
replace site-local addresses in any form, but I think the working group 
has made it clear that this is not a reasonable alternative.

I would like to hear from the working group on how we should proceed.  I 
think the choices are:

A) Deprecate Site-Local addresses independently from having an alternative 
solution available.  This would mean that the working group should treat 
the deprecation, and requirements and solution documents outlined above 
independently from each other.  If there was no consensus on an 
alternative a replacement would not happen.

B) Deprecate Site-Local addresses at the same time as a alternative 
solution is agreed to.  This would mean advancing both documents at the 
same time and making them include normative references to each other to 
insure that they were published at the same time.  This would result in 
the deprecation only happening if a consensus was reached on an alternative.

C) Deprecate Site-Local addresses after an alternative is defined, 
standardized, and in operational practice.  This would mean not advancing 
a deprecation document until there was operational evidence that the 
alternative was working and shown to be an improvement over Site-Local 
addresses.

Note:  In the above choices "Deprecate Site-Local addresses" means 
publishing an RFC that does the formal deprecation.

Please respond to the list with your preference, or if there is an 
alternative approach that is an improvement from the ones I outlined.  I 
hope that many of you will respond.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Request to Advance "IPv6 Node Requirements"

[Bob Hinden]

Thomas, Margaret,

The chairs of the IPv6 working group, on behalf of the working group, 
request that the following document be published as an Informational RFC:

Title   : IPv6 Node Requirements
Author(s)   : J. Loughney
Filename: draft-ietf-ipv6-node-requirements-05.txt
Pages   : 19
Date: 2003-8-25
A working group last call for this document was completed on 15 July 
2003.  This draft resolves issues raised during the 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://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Request to Advance "Requirements for IPv6 prefix delegation"

[Bob Hinden]

Thomas, Margaret,

The chairs of the IPv6 working group, on behalf of the working group, 
request that the following document be published as an Informational RFC:

Title   : Requirements for IPv6 prefix delegation
Author(s)   : S. Miyakawa, R. Droms
Filename: draft-ietf-ipv6-prefix-delegation-requirement-03.txt
Pages   : 7
Date: 2003-8-25
A working group last call for this document was completed on 14 July 
2003.  This draft resolves issues raised during the 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://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Weekly posting summary for ipng@sunroof.eng.sun.com

[Bob Hinden]

The chairs asked Rob Austein to starting sending out the weekly traffic 
statistics in the hope that people sending a lot of email to the list would 
show some additional restraint.  This does not appear to be working as well 
as we hoped.

I suggest to everyone if you have already said the same thing several 
times, you do not need to say it again.  Even if someone else repeated what 
you disagreed with.

Bob

At 09:00 PM 8/23/2003, Rob Austein wrote:
Messages   |  Bytes| Who
+--++--+
 25.16% |   40 | 25.68% |   216885 | [EMAIL PROTECTED]
 12.58% |   20 | 14.43% |   121847 | [EMAIL PROTECTED]
 12.58% |   20 | 11.50% |97109 | [EMAIL PROTECTED]
  4.40% |7 |  5.06% |42750 | [EMAIL PROTECTED]
  4.40% |7 |  3.85% |32475 | [EMAIL PROTECTED]
  4.40% |7 |  3.24% |27324 | [EMAIL PROTECTED]
  3.14% |5 |  4.24% |35799 | [EMAIL PROTECTED]
  3.77% |6 |  3.05% |25734 | [EMAIL PROTECTED]
  1.89% |3 |  3.57% |30164 | [EMAIL PROTECTED]
  2.52% |4 |  2.13% |17957 | [EMAIL PROTECTED]
  1.89% |3 |  1.94% |16420 | [EMAIL PROTECTED]
  1.89% |3 |  1.85% |15622 | [EMAIL PROTECTED]
  1.89% |3 |  1.74% |14682 | [EMAIL PROTECTED]
  1.89% |3 |  1.59% |13456 | [EMAIL PROTECTED]
  1.89% |3 |  1.33% |11243 | [EMAIL PROTECTED]
  1.26% |2 |  1.90% |16083 | [EMAIL PROTECTED]
  1.26% |2 |  1.41% |11921 | [EMAIL PROTECTED]
  1.26% |2 |  0.87% | 7388 | [EMAIL PROTECTED]
  1.26% |2 |  0.87% | 7330 | [EMAIL PROTECTED]
  0.63% |1 |  1.02% | 8575 | [EMAIL PROTECTED]
  0.63% |1 |  0.83% | 7047 | [EMAIL PROTECTED]
  0.63% |1 |  0.83% | 7014 | [EMAIL PROTECTED]
  0.63% |1 |  0.60% | 5098 | [EMAIL PROTECTED]
  0.63% |1 |  0.57% | 4792 | [EMAIL PROTECTED]
  0.63% |1 |  0.56% | 4696 | [EMAIL PROTECTED]
  0.63% |1 |  0.55% | 4644 | [EMAIL PROTECTED]
  0.63% |1 |  0.54% | 4583 | [EMAIL PROTECTED]
  0.63% |1 |  0.53% | 4497 | [EMAIL PROTECTED]
  0.63% |1 |  0.53% | 4436 | [EMAIL PROTECTED]
  0.63% |1 |  0.52% | 4377 | [EMAIL PROTECTED]
  0.63% |1 |  0.51% | 4332 | [EMAIL PROTECTED]
  0.63% |1 |  0.46% | 3911 | [EMAIL PROTECTED]
  0.63% |1 |  0.46% | 3852 | [EMAIL PROTECTED]
  0.63% |1 |  0.43% | 3629 | [EMAIL PROTECTED]
  0.63% |1 |  0.42% | 3541 | [EMAIL PROTECTED]
  0.63% |1 |  0.39% | 3330 | [EMAIL PROTECTED]
+--++--+
100.00% |  159 |100.00% |   844543 | Total
Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the IPv6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Some IPv6LL operational experience

[Bob Hinden]

Keith,

At 05:16 PM 8/21/2003, Keith Moore wrote:
I strongly disagree that this practice adds value to IPv6.  IMHO it has the
potential to do a great deal of harm.  It is even worse that NAT.
"Worse than NAT".  Coming from you that must be pretty bad.

Did we go to all of that trouble to deprecate SL only to find that people will
now insist that LLs are generally usable by apps?
If we're going to make IPv6 even less predictable and less functional than
IPv4, why did we bother?
I see it another way.  It seems to me that in cases where there are no 
routers, globally assigned prefixes, DNS, servers, etc., if nodes can 
discover each others IPv6 link-local addresses and use them for 
communications, this is a good thing.  Especially when the alternative is 
for them to not communicate at all.  I think this is a very legitimate use 
of IPv6 link-local addresses and do not think we should restrict it (even 
if we could).  Note that I don't think it is trivial to do this and that 
there are no issues with the transition between this environment and a 
global environment.  Nor do I think we should put IPv6 link-local address 
in the global DNS.

My other point was that IPv6 suffers from only adding value when everyone 
else has it and there is global IPv6 connectivity.  I think it is a good 
thing if people find good uses for IPv6 with needing everyone else to have 
it first.  I think this will have the effect of getting us to global IPv6 
faster.  It give people local incentive to use it.  I think this is a good 
thing.

Bob

p.s. Please accept that we may disagree about this.




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Some IPv6LL operational experience

[Bob Hinden]

Joshua,

At 10:24 PM 8/20/2003, Joshua Graessley wrote:

I realize that as an employee of a company that sells a product and tries 
to implement standards the IETF blesses to solve problems, my voice 
doesn't really count, but I wanted to toss in my two cents.
I hope you were being sarcastic, but I think you voice should count a 
lot.  The goal of IETF standardization is interoperability and getting 
operational experience is very important.

We have been using IPv6LL addresses with some success. The next release of 
Mac OS X implements something similar to LLMNR that we call mDNS with 
support for IPv6. For the time being, the only IPv6 addresses we, or most 
of our customers have, are IPv6LL addresses. This combination of mDNS and 
IPv6LL addresses works very well. IPv6LL addresses are important to us 
because a multi-homed host may not have an IP address on every interface. 
IPv4LL addresses don't work on more than one interface because they lack a 
scope id. The scope id in IPv6LL addresses makes them much more compelling.

IPv6LL addresses let us enable networking in situations that wouldn't 
otherwise work. For example, we've implemented IP and IPv6 over Firewire. 
In most cases, it is unlikely that an IPv4 address will be assigned to the 
IP over Firewire link. This is usually used in the scenario where two 
computers are hooked directly together. We can't assign an IPv4LL address 
to the Firewire interface because it causes a number of problem on a 
multi-homed host. The IPv6LL address is configured automatically and is 
always there. Very few people have the skill required to successfully type 
an IPv6 address, which is why the mDNS component is so important. In 
addition to allowing users the ability to type a name instead of an 
address, the question of scope id goes away. The name is resolved using 
mDNS. The scope id is derived from the interface the response came back 
from. The application is none the wiser because it gets a full 
sockaddr_in6 from the call to resolve the name.

Applications that perform referrals may fail, but I'm not aware of any of 
these that are currently shipping and support IPv6. IPv6 is a new beast, 
we don't have to be as concerned about applications making stupid 
assumptions. If we explain that IPv6 link local addresses work this way 
and here's a list of limitations, that's good enough. The advantages of 
IPv6 link-local addresses far outweigh the disadvantages.

IPv6LL is a major selling point. IPv6LL is a sneaky way to get everyone 
exposed to IPv6 and to encourage developers to start supporting IPv6. 
Sure, connectivity off of the local link for those of us in the US is only 
for a few elite, but IPv6 on the local link can solve real world problems 
today and work for everyone.
Thanks for describing this.  The local discovery and communication problem 
is important.  I also think this is an important approach because it uses 
IPv6 in a local environment in a way that adds value without the need for 
it to be available globally.  It adds value without the need for everyone 
else to do it first.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Moving the ipng mailing list

[Bob Hinden]

Ronald,

Can the list be moved to a server that supports IPv6 transport? E.g.,
it looks like all the ops.ietf.org lists are delivered over IPv6 now.
I agree that it would be good to have the list on a site that supports 
IPv6.  However, I think it would be even better to get ietf.org to add IPv6 
support so all IETF content and lists will be accessible with IPv6.

I periodically ask the IETF chair about this.  I suggest that anyone who 
thinks it is important for ietf.org to support IPv6 to send mail to the 
IETF chair.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Moving the ipng mailing list

[Bob Hinden & Margaret Wasserman]

Folks,

After many years of service Sun Microsystems has indicated that they can no 
longer administer the ipng mailing list of the IPv6 working 
group.  Consequentially, we will be moving the list in next two or three 
weeks.  Sun will continue to manage the list through the transition.

We first want to thank the folks at Sun for keeping the list going and 
dealing with bounces, spam, and all of the other things that come up with a 
large public mailing list.  This has been an important contribution to the 
IPv6 working group and the IETF in general.  Thank you!!!

The current plan is to move the list to ietf.org.  Everyone currently 
subscribed to [EMAIL PROTECTED] will be subscribed to the new 
list.  You will not have to subscribe to the new list if you are currently 
subscribed to the old one.  This should keep the disruption of moving to a 
minimum.

Once the new list is set up and announced as operational, we will ask Sun 
to setup a fixed error message in response to any posting to the old 
address saying the list has moved and ask the sender to resend the email to 
the new list address.

We need a volunteer to be the list owner to handle the bounces, SPAM, 
etc.  This is an important job.  If you are interested in doing this, 
please respond directly to the chairs and include any experience you have 
doing this for other lists.  Having a few people share this job would be fine.

One small point.  The list is currently named "ipng".  We could keep the 
name the same 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



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Moving forward on Site-Local and Local Addressing

[Bob Hinden]

Patrik,

The more it is for the end-user and basic administrator (and application) 
"just more bits", the better.
YES!  From the users perspective, the only difference should be that they 
get to run new cool applications that were not available to them previously 
(due to IPv4's limitations, NATs, etc.).

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Fourth alternative [was Re: Moving forward ....]

[Bob Hinden]

Erik,

At 07:02 AM 8/19/2003, Erik Nordmark wrote:
I didn't know there were such side effects associated with accepting that
as a WG document.
My assumption was that it was a fine thing to work on possible replacements
and to understand the cost/benefit tradeoffs of such replacements.
But presumably the WG should be capable to still say "we don't like any of
them".
Your logic seems to preclude such a conclusion.
I don't think it precludes such a conclusion in the future as any solution 
will need to go through normal IETF processes to advance.  But I do think 
it represented a reasonable conclusion at the time based on the Vienna IETF 
sessions and subsequent discussion.

FWIW, I think a multi6 solution with id/loc separation will make the
local addressing concerns go away.
Also FWIW, I think opinions differ on this topic and we will know more when 
there is a specified solution so it's benefits and weaknesses can be 
evaluated.  I note that people have been talking about for almost as long 
as IPv6 has been around.  However, I think it would be unwise for the 
working group to defer what we can do now in this area to wait for this to 
happen.  When or if it happens, it's benefits will encourage everyone to 
adopt it quickly.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 Link-Local Use Issue for Applications

[Bob Hinden]

Mark,

b) There have been cases where manufacturers have allocated non-unique MAC 
addresses. What is worse is that these duplications have apparently tended 
to happen within the same batch of NICs, and have been encountered when 
somebody goes to deploy a group of say 20 new NICs they have just bought, 
and encounter one or more duplications.
Do you have any first hand experience of this happening?  I have heard the 
story several times, but I would like to see something definitive.  I 
wonder if it is an "internet urban myth".

Does anyone have in their possession two or more NICs with the same MAC 
address?

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

RE: Moving forward on Site-Local and Local Addressing

[Bob Hinden]

Jim,

At 07:18 AM 8/9/2003, Bound, Jim wrote:
> We now have a combined local addressing requirements document
> , a specific
> alternative to
> site-local addresses draft
> 
> (accepted as a working group item at the Vienna IETF)
Why do we need both of these?  We just need the hinden work.  The
templin/hain work could be INFO or BCP with some fixing?
Is that the thought?
Yes, that is the plan.  The hain-templin document would be published as 
Informational.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Moving forward on Site-Local and Local Addressing

[Bob Hinden]

Thanks to everyone who has responded with a preference so far.  Please keep 
them coming.

To make it a little easier to keep track of the results, please only use 
the above subject for direct responses.  Move discussions to other Subjects.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Appel due to management of the "site-local issue"

[Bob Hinden]

Leif,

You didn't address this to me, but I feel obligated to answer.

The questions I have asked the working group in the email "Moving forward 
on Site-Local and Local Addressing" was to ascertain the manner in which 
the working group wanted the deprecation of site-local was to happen.  The 
steps the working group should take.  This has been a topic of debate it 
and I thought it best to get feedback from the working group.

It was not in any way an attempt to revisit or un-deprecate 
site-locals.  Each choices I asked people to indicate their preference for 
in that email included deprecating site-local addresses.  I support that 
the working group did decide to deprecate site-local addresses, helped to 
declare that consensus, and I am one of the w.g. chairs who rejected the 
appeal on that topic to overturn the decision.  The chairs are not trying 
to change the decision of the working group.

I think you may be misinterpreting the intent of this email.  Site-Local 
is, as everyone can see, a contentious issue and it is my desire get 
clarity on the way the WG wants to move forward.  Getting feed back from 
the working group on how it wants to do this is something I feel is essential.

Regards,
Bob
At 02:41 AM 8/5/2003, Leif Johansson wrote:


During the IETF meeting in San Francisco, rough consensus found that 
site-local was to be deprecated.
The wg was to investigate other approaches to the problems site-local 
claims to solve. It should be noted
that the wg chairs explicitly before the meeting in San Francisco asked 
people not directly involved in
ipv6 design (security, routing and applications people) to get involved 
with this issue. In my opinion
from talking to a number of collegues and from the traffic on the mailing 
list those involved from other
areas are no longer actively participating in the debate since they 
believe that site-locals has indeed been deprecated and that the ipv6 wg 
is continuing the important work on ipv6 in the IETF.

Currently the question about the future and status of site-locals is again 
beeing discussed in the wg
despite the fact that consensus was achieved in SF and confirmed on the 
mailing-list. This is a sign that
the wg chairs have not been able to follow the plan laid out at the SF 
meeting.

I respectfully ask that the ADs to confirm the decision made in San 
Francisco, later confirmed on the
mailing list, and ask the wg chairs to please move on, working on real 
issues regarding ipv6 than beating
this dead horse once again.

  Best Regards
  Leif Johansson
  Stockholm university



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Fourth alternative [was Re: Moving forward ....]

[Bob Hinden]

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.
That is correct.   Also, any specific alternative will have to go through 
the normal w.g. and IETF processes so it's not done until the RFC is published.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

RE: Fourth alternative [was Re: Moving forward ....]

[Bob Hinden]

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 ignore 
announces that fall in the special prefix unless a /48 has been 
explicitly. As a result, even if someone convinces their local ISP, they 
will not be able to get connectivity to the whole Internet, and the 
addresses will not be usable as "globally routed PI." In fact, we should 
do that.
I agree, and it is already in the draft.  The current draft includes text 
on this in two places.

In section 4.0 "Routing":

   Any routing protocol that is used between sites is required to filter
   out any incoming or outgoing Local IPv6 unicast routes.  The
   exception to this is if specific /48 IPv6 local unicast routes have
   been configured to allow for inter-site communication.
   If BGP is being used at the site border with an ISP, by default
   filters MUST be installed in the BGP configuration to keep any Local
   IPv6 address prefixes from being advertised outside of the site or
   for these prefixes to be learned from another site.  The exception to
   this is if there are specific /48 routes created for one or more
   Local IPv6 prefixes.
and in section 6.0 "Site Border Router and Firewall Filtering":

   While no serious harm will be done if packets with these addresses
   are sent outside of a site via a default route, it is recommended
   that they be filtered to keep any packets with Local IPv6 destination
   addresses from leaking outside of the site and to keep any site
   prefixes from being advertised outside of their site.
   Site border routers SHOULD install a black hole route for the Local
   IPv6 prefix FC00::/7.  This will insure that packets with Local IPv6
   destination addresses will not be forwarded outside of the site via a
   default route.
   Site border routers and firewalls SHOULD NOT forward any packets with
   Local IPv6 source or destination addresses outside of the site unless
   they have been explicitly configured with routing information about
   other Local IPv6 prefixes.  The default behavior of these devices
   SHOULD be to filter them.
Is this sufficient?  Would it better to also include an "operational 
considerations" or similar section?  More text on why this is important?

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Fourth alternative [was Re: Moving forward ....]

[Bob Hinden]

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 that this is not a 
reasonable alternative.
It's from my reading of the discussion (on the mailing list and in the 
meetings) and the fact that the working group decided to accept 
 as a working group document in 
Vienna.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Moving forward on Site-Local and Local Addressing

[Bob Hinden]

Dan,

It occurs to me that if we are going to start actually counting again
(picking the option with the most votes) the options offered will tend
to skew the result towards A by splitting the site-local support between
B & C.  Therefore I wish to cast my vote against A more than for C...
I am planning to publish the raw results so everyone can see all of the 
data before drawing any conclusions.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Moving forward on Site-Local and Local Addressing

[Bob Hinden]

[no hats on]

Then, we have a  'requirement' document that pretend to explain why we need
'local' addresses. If you read it carefully, and as acknowledged by one of 
its main
author in Vienna, almost all of those requirements (if not all) would be 
fulfilled
by provider independent addresses. Actually, there is nothing in it that
explain why we need 'local range' addresses. The essence of those
requirements is in the need for stable addresses that are
independent from ISPs.
If this means non-globally routable provider independent addresses (e.g., 
 ), then I am in agreement that 
a solution doesn't have to be limited in scope (or range) like site-local 
addresses are.

If this means globally routable provider independent addresses.  Then it 
is, of course, correct that this would solve many of the problems 
too.  Unfortunately, there is a big problem why this isn't a practical 
choice we can make now.   We don't have, IMHO, any idea how to make 
globally routable provider independent addresses work at scale in the 
Internet.  There are a number of problem area.

We don't know how to route them at the scale of the current Internet.  The 
current routing technology we have now would have to treat each provider 
independent prefix as a separate route.  That would be one route per 
organization.  That is way too many routes to be handled by anything close 
to current technology and products.  It would be turning off aggregation.

If we had new routing technology that could handle globally routable 
provider independent addresses, then it would have to be deployed in most 
routers in the Internet before it would be useful.  Probably all routers 
from the site boundary to the core of the Internet.  Given that I suspect 
any solution in this area would not be an incremental changes to a routers 
implementation (i.e., not another BGP extension), perhaps even changes to 
the routers route lookup engines (in hardware in many cases) this would 
likely take a long time to accomplish.  Also, a bit of a chicken and egg 
deployment problem that everyone working on IPv6 understands too well.

We don't have any structure in place to allocate and register these types 
of addresses.  The registries might be able to do it, but as they are 
currently structured they are mostly focused on ISPs, not individual 
sites.  This would require some major changes in their structure and 
perhaps funding models. Right now every site would have to be an LIR.

Assuming routing technology was available and all of the routers were 
modified  to support the new routing technology, then there would have to 
be some incentive for the ISP to want to carry these type of routes.  They 
are great for the customers, but it makes it easy for their customers to 
switch ISPs.  We have seen how well the phone providers have embraced 
provider independent phone numbers.  They only "agreed" to support them 
after governmental action.  I suspect ISP might not be widely enthusiastic 
to deploy them.

So overall if we had all of these problems solved it would be 
great.  Beside just the local address problems, it would deal with site 
multihoming, site mobility, change of ISP, and more.  It's a great problem 
to work on as the benefits are many.  But I don't think we will see 
solutions to these problem in the near or medium terms.  I think the 
routing problem is a significant research topic that people have been 
working on for a long time.

Until solutions two these problems are available, I don't see this as a 
viable alternate to the current approaches.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Moving forward on Site-Local and Local Addressing

[Bob Hinden]

[IPv6 working group chair hat on]

I think the working group has been making good progress on replacing 
site-local addresses and wanted to get feed back from the working group on 
how we should move forward.  This is not intended to directly relate to the 
ongoing appeal of the working groups decision to deprecate the usage 
site-local addresses, but to get feedback on how to proceed.  I think it is 
very important that we move forward on this issue and not rehash what has 
happened in the past.

We now have a combined local addressing requirements document 
, a specific alternative to 
site-local addresses draft  
(accepted as a working group item at the Vienna IETF), and will soon have a 
draft describing why site-local addresses are being deprecated and doing 
the formal deprecation (authors identified and outline discussed at the 
Vienna IETF).  Note that all of these documents will proceed through the 
normal working group and IETF processes of last calls and review.

I think legitimate questions have been raised about how the working group 
should go about deprecating site-local addresses given their maturity in 
the current specifications and use in deployed products.  Specifically 
should they be deprecated independently from having an alternative solution 
available, at the same time an alternative is available, or sometime after 
an alternative is available.  A forth alternative is to not replace 
site-local addresses in any form, but I think the working group has made it 
clear that this is not a reasonable alternative.

I would like to hear from the working group on how we should proceed.  I 
think the choices are:

A) Deprecate Site-Local addresses independently from having an alternative 
solution available.  This would mean that the working group should treat 
the deprecation, and requirements and solution documents outlined above 
independently from each other.  If there was no consensus on an alternative 
a replacement would not happen.

B) Deprecate Site-Local addresses at the same time as a alternative 
solution is agreed to.  This would mean advancing both documents at the 
same time and making them include normative references to each other to 
insure that they were published at the same time.  This would result in the 
deprecation only happening if a consensus was reached on an alternative.

C) Deprecate Site-Local addresses after an alternative is defined, 
standardized, and in operational practice.  This would mean not advancing a 
deprecation document until there was operational evidence that the 
alternative was working and shown to be an improvement over Site-Local 
addresses.

Note:  In the above choices "Deprecate Site-Local addresses" means 
publishing an RFC that does the formal deprecation.

Please respond to the list with your preference, or if there is an 
alternative approach that is an improvement from the ones I outlined.  I 
hope that many of you will respond.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Fwd: I-D ACTION:draft-hain-templin-ipv6-limitedrange-00.txt

[Bob Hinden]

This is the combined Tony Hain and Fred Templin requirements 
document.  Many thinks to Tony and Fred for getting this out quickly.

Bob


To: IETF-Announce: ;
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-hain-templin-ipv6-limitedrange-00.txt
Date: Mon, 04 Aug 2003 10:14:30 -0400
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title   : Limited Range Addressing Requirements
Author(s)   : T. Hain, F. Templin
Filename: draft-hain-templin-ipv6-limitedrange-00.txt
Pages   : 18
Date: 2003-8-4
The IPv6 addressing architecture specifies global and local-use
unicast addressing schemes, but provides no operational guidelines or
requirements for their use. There is a strong requirement for
addressing that is limited to a bounded domain of applicability, or
range. This memo will discuss requirements for limited range
addressing.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-limitedrange-00.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hain-templin-ipv6-limitedrange-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-hain-templin-ipv6-limitedrange-00.txt".
NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
ENCODING mime
FILE /internet-drafts/draft-hain-templin-ipv6-limitedrange-00.txt


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Draft Minutes from Vienna IETF

[Bob Hinden]

The draft minutes from the IPv6 working group sessions at the Vienna IETF 
are attached.  Please review and send us comments and corrections.

Thanks,

Bob Hinden & Margaret WassermanIPv6 WG Minutes 
July 14 & 17, 2003
IETF57 -- Vienna, Austria
=

CHAIRS: Bob Hinden <[EMAIL PROTECTED]>
Margaret Wasserman <[EMAIL PROTECTED]> 

Minutes taken by Margaret Wasserman and Bob Hinden.

AGENDA:

Monday July 14, 2003

   Introduction and Agenda Bashing -- Bob Hinden (5 min)
   Document Status and Priorities -- Bob Hinden (10 min)
   Open Issues with IPv6 Node Requirements -- John Loughney (15 min)
   Open Issues with IPv6 MIBs -- Brian Haberman (10 min)
   Open Issues with Prefix Delegation Requirements -- Shin Miyakawa (10
  min)  
   Bridge-like Neighbor Discovery Proxies -- Dave Thaler (15 min)
   IPv6 Node Information Queries -- Bob Hinden (15 min)
   IPv6 Socket API for source address selection -- Samita Chakrabarti (10
  min) 
   Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming
   Shen (5 min) 

Thursday, July 17, 2003

   Introduction and Agenda Review -- Bob Hinden (5 min)
   Open Issues with Scoped Address Architecture -- Jinmei Tatuya (10 min)
   Requirements for Local Addressing:
   Local Addressing Requirements -- Tony Hain & Juha Wiljakka (20 min)
   General Discussion of Local Addressing Requirements -- Chairs (30 min) 
   Unique Local IPv6 Unicast Addresses -- Bob Hinden (20 min)
   Site-Local Deprecation Document Plan -- Christian Huitema (30 min) 

--

Introduction and Agenda Bashing -- Bob Hinden
---------

Bob Hinden announced an IPv6 Interoperability event in 
September in Brussels.  For more information see:

   http://www.etsi.org/plugtests

Plan is to discuss short topics and normal business today,
and use Thursday primarily for local discussion topic.  
There were no comments or changes to the agenda.


Document Status and Priorities -- Bob Hinden


   (See slides)

James Kempf asked if the Neighbor Discover changes are related to a
mobility draft on Friday.  Bob Hinden explained that we are making
updates for minor issues and hope to recycle at Draft Standard.  Major
changes or new features should be considered independently.

Discussion of dropping PPP.  Alex Conta thinks that we should update it
for specific changes, which he will send to the list.


Open Issues with IPv6 Node Requirements -- John Loughney


http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-04.txt

   (See slides)

The document is currently in last call, and needs to be updated to
address 14 issues.

Bob Hinden suggested that the Path MTU issue might be better resolved by
referencing the recommendations in the Path MTU document as it is covered
in detail there.  John Loughney agreed.

 mentioned that SSM is in last call and that it should be referenced
in this group.  She will send proposed text to the WG.  Bob Hinden raised
concern that we may not want to be dependent on SSM if it is still a
draft.  Brian Haberman pointed out that it is already in the IESG, so
this may not be a problem.

Hesham asked if we should change the name of the document to host
requirements, since we aren't including router requirements.  John
Loughney will work on some text for the introduction that makes this
clear, if it isn't there already.  Dave Thaler pointed out that we should
have a section labeled "router requirements" unless it lists all of the
router requirements.

Alex Conta raised the issue that if neither Path MTU or fragmentation is
mandatory, you can run into problems.  Dave Thaler pointed out that RFC
2460 requires that you support fragmentation reassembly or that you send
"too big" message.  This isn't in the Path MTU document.  There is a
difference between what is required for hosts and routers in this regard.
Alex Conta agreed.

Rob Austein asked if there are DOCSIS devices that use MIBs but don't
support SNMP.  Margaret Wasserman pointed out that DOCSIS devices do
support SNMP.  Some discussion of the fact that while devices SHOULD be
manageable, SNMP is a MAY.  Rob agreed that this addressed his issue.

Dave Thaler raised issue about what we do when a normative reference is
obsoleted by a newer one.  Do we assume that the requirement will follow
forward to a successor?  If so, we could only include references for the
currently published version.  Christian suggested that we remove
references to anything that isn't published yet.  Bob Hinden and John
Loughney agreed that we should review current status and decide what make
sense in each case.

Alain Durand raised concern about the fact that we might not have any
requirement for DNS discovery in the host requirements if the

test, please ignore

[Bob Hinden]

test, please ignore.


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Draft IPv6 Agenda for the Vienna IETF

[Bob Hinden & Margaret Wasserman]

Here is the draft agenda for the IPv6 sessions for the Vienna IETF 
meeting.   Please send comments and corrections to the chairs.

Thanks,
Bob Hinden & Margaret Wasserman
--

IPv6 (ipv6) Working Group Agenda
IETF 57 -- Vienna, Austria
July 13-18, 2003
Monday, 1930-2200 (Hall F2)
===
Introduction and Agenda Bashing -- Bob Hinden (5 min)

Document Status and Priorities -- Bob Hinden (10 min)

Open Issues with IPv6 Node Requirements -- John Loughney (15 min)
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-04.txt
Open Issues with IPv6 MIBs -- Brian Haberman (10 min)
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2011-update-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2096-update-04.txt
Open Issues with Prefix Delegation Requirements -- Shin Miyakawa (10 min)
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-prefix-delegation-requirement-02.txt
Bridge-like Neighbor Discovery Proxies -- Dave Thaler (15 min)
http://www.ietf.org/internet-drafts/draft-thaler-ipv6-ndproxy-00.txt
IPv6 Node Information Queries -- Bob Hinden (15 min)
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-10.txt
IPv6 Socket API for source address selection -- Samita Chakrabarti (10 min)
http://www.ietf.org/internet-drafts/draft-chakrabarti-ipv6-addrselect-api-01.txt
Link Name and Sequence Options for IPv6 Neighbor Discovery -- Naiming Shen 
(10 min)
http://www.ietf.org/internet-drafts/draft-shen-ipv6-nd-name-seq-options-01.txt

Thursday, 0900-1130 (Hall F2)
=   
Introduction and Agenda Review -- Bob Hinden (5 min)

Open Issues with Scoped Address Architecture -- TBD (10 min)
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-00.txt
Requirements for Local Addressing:

Local Scope Address Requirements -- Tony Hain (15 min)
http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt
Requirements for Limited-Scope Unicast Addressing -- Juha Wiljakka (15 
min)
http://www.ietf.org/internet-drafts/draft-templin-lsareqts-00.txt

General Discussion of Local Addressing Requirements -- Chairs (30 min)

Unique Local IPv6 Unicast Addresses -- Bob Hinden (20 min)
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt
Site-Local Deprecation Document Plan -- Christian Huitema (30 min)

---


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "Requirements for IPv6 prefix delegation"

[Bob Hinden & Margaret Wasserman]

This is a short IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

Title   : Requirements for IPv6 prefix delegation
Author(s)   : S. Miyakawa, R Droms
Filename: draft-ietf-ipv6-prefix-delegation-requirement-02.txt
Pages   : 6
Date: 2003-7-1
A two week working group last call was completed on March 17, 2003 on the 
-01 version of the document.  This version resolves issues raised during 
that working group last call.

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  This last call period will end on 14 
July 2003.

Bob Hinden / Margaret Wasserman


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-02.txt

[Bob Hinden]

The significant (non-editorial) change in this version of the draft was 
changing the title and name of addresses to "Unique Local IPv6 Unicast 
Addresses" with abbreviation of "Local IPv6 addresses".  The authors 
believe this is a more accurate description and makes the document read better.

Bob

To: IETF-Announce: ;
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-02.txt
Date: Wed, 02 Jul 2003 16:31:21 -0400
Sender: [EMAIL PROTECTED]
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title   : Unique Local IPv6 Unicast Addresses
Author(s)   : R. Hinden
Filename: draft-hinden-ipv6-global-local-addr-02.txt
Pages   : 13
Date: 2003-7-2
This document defines an unicast address format that is globally
unique and is intended for local communications, usually inside of a
site.  They are not expected to be routable on the global Internet
given current routing technology.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hinden-ipv6-global-local-addr-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt".
NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
ENCODING mime
FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-02.txt


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "Management Information Base for the TCP"

[Bob Hinden & Margaret Wasserman]

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

Title   : Management Information Base for the Transmission
  Control Protocol (TCP)
Author(s)   : B. Fenner et al.
Filename: 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


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "Management Information Base for the Internet Protocol"

[Bob Hinden & Margaret Wasserman]

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

Title   : Management Information Base for the Internet Protocol
  (IP)
Author(s)   : S. Routhier
Filename: draft-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


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "IPv6 Node Information Queries"

[Bob Hinden & Margaret Wasserman]

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

Title   : IPv6 Node Information Queries
Author(s)   : M. Crawford
Filename: draft-ietf-ipngwg-icmp-name-lookups-10.txt
Pages   : 12
Date: 2003-6-27
This document was previously sent to the IESG for Proposed Standard.  The 
IESG responded with a number of comments.  The IESG discussion can be found 
at:

 https://www.ietf.org/IESG/EVALUATIONS/draft-ietf-ipngwg-icmp-name-lookups.bal

The chairs believe that this draft resolves the issues raised by the 
IESG.  Given the time that has elapsed, we thought it was important to have 
another working group last call.  Changes in this draft include:

 - Move applicability statement to start of document and update
   introduction.
 - Removed Qtypes query capabilities
 - Limit returned TTL in node name to zero and removed text describing
   non-zero TTLs.
 - Remove text about A6 records
 - Change to have all new Qtypes require IETF approval
 - Updated security considerations
The reasoning behind this set of changes was to resolve the issues raised 
by the IESG and to maintain comparability with current shipping code.  Node 
Information Queries is shipping in the KAME and USAGI distributions and has 
been found to be very useful for deploying IPv6 service and debugging 
operational problems.

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


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "IPv6 Node Requirements"

[Bob Hinden & Margaret Wasserman]

This is a IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

Title   : IPv6 Node Requirements
Author(s)   : J. Loughney
Filename: draft-ietf-ipv6-node-requirements-04.txt
Pages   : 20
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 IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

RE: Requirements for Limited-Scope Unicast Addressing in IPv6

[Bob Hinden]

Michel,

At 09:50 PM 6/20/2003, Michel Py wrote:
> Fred Templin wrote:
> A limited-scope addressing scheme is needed to replace the
> now-deprecated site-local scheme from [RFC3513]
The site-local scheme is not deprecated until there is a published
document that states otherwise which will not happen until all the
outstanding appeals have been resolved. Therefore the site-local scheme
from RFC3513 which is in the standards track is still valid. Should you
push this text to be published I can assure you that it will be appealed
as well all the way to the IAB.
Your email saying that this work can not proceed or it will be appealed is 
out of line and an attempt to intimidate the IPv6 working group.  This is 
unacceptable and inconsistent with open IETF participation.  There is an 
appeal outstanding regarding the IPv6 working groups decision to deprecate 
site-local addresses, but until and if that decision of the working group 
is overturned, we will continue working under that decision.  You may make 
your own decision about whether or not to participate in this activity.

Bob Hinden
IPv6 w.g. co-chair

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 Address validation

[Bob Hinden]

Tatuya-san,

   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
  hexadecimal values of the eight 16-bit pieces of the address.
Some people interpret "01234" as a 16-bit piece, and others do not.
If we can only refer to this text, I don't think we can go further.
I don't think this case was considered explicitly, but in the tradition of 
"be liberal in what one receives" as long as the string results in 16-bits 
I think it is OK for an implementation to accept it.  Another reason why I 
think this is OK is that the document also allows for less then four hex 
digits.  In my view this confirms that there isn't a strict requirement for 
a number of digits, only that the field results in 16-bits.  So "0", "01", 
"0123", and "01234" are OK, but "12345" is not.

Meanwhile, a recent draft draft-main-ipaddr-text-rep-00.txt points out
that RFC 2373, the previous version of the address architecture RFC,
had an ABNF than invalidated "01234":
  IPv6address = hexpart [ ":" IPv4address ]
  IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
  IPv6prefix  = hexpart "/" 1*2DIGIT

  hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
  hexseq  = hex4 *( ":" hex4)
  hex4= 1*4HEXDIG
And the draft itself defines a revised and precise version of the
ABNF, which also prohibits "01234" from being used as a "16-bit
piece."
I don't remember why the ABNF was removed in RFC 3513, but, regardless
of the reason, I believe the address architecture authors actually
intend at most four hex digits.
The ABNF was removed from the document because what was specified was 
broken and at the time we couldn't find a working replacement.

So, assuming we can agree on draft-main-ipaddr-text-rep-00.txt and the
draft will clarify RFC 3513, can we conclude here that inet_pton()
should reject more than four hex digits as a 16-bit piece?
I don't see the need as long as the result is 16-bits, but would like to 
see if there are other opinions.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Document Action: IPv6 Global Unicast Address Format to Informational

[Bob Hinden]

Margaret,

I just submitted it.

Bob

At 09:52 AM 6/19/2003, Margaret Wasserman wrote:
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




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Request for Agenda Items

[Bob Hinden & Margaret Wasserman]

Margaret Wasserman and I have requested two slots for the Vienna IETF.  We 
requested a short slot (~1 hour) and a long slot (~2 1/2 hour).We plan 
to use the short slot for status and short open issues, and use the longer 
slot for topics that need more discussion time (e.g., local addressing).

Please send us requests for agenda items (including time needed).  We will 
give priority in setting the agenda to current working group documents and 
work items identified in the working group charter.

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://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

test, please ignore

[Bob Hinden]

1 2 3 4


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt

[Bob Hinden]

FYI.  Changes include:

  o Added section on scope definition and updated application
requirement section.
  o Clarified that, by default, the scope of these addresses is
global.
  o Renumbered sections and general text improvements
  o Removed reserved global ID values
  o Split Global ID values into centrally assigned and local
assignments and added text to describe local assignments
  o Added pseudo code for local allocation submitted by Brian
Haberman and added him as an author.
The draft continues the use of the FC00::/7 prefix as I didn't see (as the 
author) a clear consensus to change it.

Bob

To: IETF-Announce: ;
From: [EMAIL PROTECTED]
Reply-to: [EMAIL PROTECTED]
Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt
Date: Fri, 13 Jun 2003 07:51:35 -0400
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title   : Globally Unique IPv6 Local Unicast Addresses
Author(s)   : R. Hinden
Filename: draft-hinden-ipv6-global-local-addr-01.txt
Pages   : 13
Date: 2003-6-12
This document defines an unicast address format that is globally
unique and is intended for local communications, usually inside of a
site.  They are not expected to be routable on the global Internet
given current routing technology.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-hinden-ipv6-global-local-addr-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt".
NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
ENCODING mime
FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-01.txt


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: null-routed aggregated global unicast (was: another view of fc00::/7)

[Bob Hinden]

Pekka,

Good points.

With current RIR rules, *no* ISP can give an absolute guarantee that it's
prefix couldn't, at one point, be pulled off.
That is consistent with my understanding of the RIR policies.  I think they 
go to some length to make it clear that the prefixes allocated to an ISP 
are not owned by the ISP and to their customers.  For example section 4.1 
of RIPE267

 http://www.ripe.net/ripe/docs/ipv6policy.html

 4.1. Address space not to be considered property

 It is contrary to the goals of this document and is not in the
 interests of  the Internet community as a whole for address space
 to be considered freehold property.
 The policies in this document are based upon the understanding that
 globally unique IPv6 unicast address space is licensed for use rather
 than owned. Specifically, IP addresses will be allocated and assigned
 on a license basis, with licenses subject to renewal on a periodic basis.
 .
So, it seems to me that creating implicit assumption that addresses
allocated today from RIR's are "magical" and "will never be revoked", and
"the ISP can give legal guarantees the prefix will never clash".
It seems to me that *practically*, recurring fees are a feature.  If an
ISP goes bankrupt, some other ISP actually has an incentive to obtain its
business and the prefix -- in hope of getting a share of those recurring
fees :-).  Otherwise, the prefix could just rot and be returned to RIR
(for example).
In this case there is also the problem that if the contact information for 
the allocation is lost or out of date, then it will be difficult for 
whoever obtains the assets of the bankrupt ISP to determine if the 
allocation is still in use.  Consequently there is a reasonable likelihood 
that it will be reassigned to someone else and made routable.

The more I think about it the less I like the idea that prefixes from the 
globally routable address space will be used for local addressing.  I 
understand there isn't anything that can stop this from happening 
occasionally, but I strongly doubt that it would ever become official RIR 
policy.

Bob




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: null-routed aggregated global unicast (was: another view of fc00::/7)

[Bob Hinden]

jj,

At 09:04 AM 6/10/2003, Shannon -jj Behrens wrote:
Earlier, I suggested that an ISP could delegate addresses out of its
existing aggregated, global unicast address block for free without
providing connectivity.  Having seen all of the email on this subject,
I believe that such an ISP could actually sell prefixes for which it
doesn't provide direct connectivity.  Such addresses could be used for
VPN's, etc. without fear of collision.  Traffic destined to such
addresses on the Internet would be aggregated to the ISP, and probably
sent to /dev/null.  For an additional fee, the ISP could tunnel such
traffic back its customers.  The prefixes would be sold for a fixed,
one-time fee.
Is this just another form of a registry?  Also, a lot of the motivation for 
this type of addresses was to get addresses that are provider 
independent.  While they are not intended to be routable, the seem provider 
oriented to me.

Also, it doesn't by itself, meet the need of people who want to be able to 
create a prefix locally.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

FEC0::/10 vs. FC00::/7

[Bob Hinden]

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.

I think one element in the choice comes down to deciding if we want the 
default scope of these addresses to be global.  Currently the FEC0::/10 
prefix is called out in RFC3513 for special handling and everything else 
not listed (including FC00::/7) is to be treated as global unicast.

If we want these addresses to be handled differently from global unicast 
(like giving them preference over global unicast), then using the FEC0::/10 
prefix is a good choice.  If we want them to be treated the same as other 
global unicast than using FC00::/7 would be preferable.

Note that RFC3515 does allow for other specifications to define special 
handling for other prefixes, but as Alain Durand pointed out on the list 
doing so does put some additional burden on existing implementations.

Other opinions?

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

RE: Status of

[Bob Hinden]

Christian,

Isn't that cool? We had this discussion before. In the spring of 1997,
as a matter of fact. And the suggestion then was:
> Date: Tue, 13 May 1997 11:25:42 -0400
> From: [EMAIL PROTECTED] (Christian Huitema)
> Subject: (IPng 3627) Re: W.G. Last Call on "Advanced Sockets API for
In hindsight, we should have listened to you back in 1997.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Status of

[Bob Hinden]

KRE,

Hence, I see no real reason at all to stray from FEC0::/10 - and lots
of reasons to remain in that space.
I think you are suggesting that the draft be changed to reuse the FEC0::/10 
space with a resulting 38-bit global ID.  This would allow for 
274,877,906,944 prefixes, or 30 per person in 2050.

My preference would be for a larger global ID, but I would like to hear 
what other folks think.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Status of

[Bob Hinden]

[My opinions as document author]

Overall I believe there is general agreement that this type of address is 
an improvement over site-local because the prefixes are unique.

Below is my summary of conclusions reached and open issues raised on the 
mailing list.

1) A global-ID of 41 bits is a reasonable choice.

2) It is important to allow for /48 prefixes (with 16-bit subnet IDs) to 
maintain compatibility with RFC3177.

3) The central allocation proposed in the draft is OK for some situations, 
but there is also need for local allocation for sites who can not want to 
use a central allocation authority.  Pseudo-random numbers is a reasonable 
choice for this given the field size..  The suggestion made on the list to 
split FC00::/7 into FC00::/8 and FD00::/8 to allow for each type of 
allocations is a good approach.

I plan to make this change in the next version of the draft and include 
pseudo-code of an local allocation algorithm.  Brain Haberman is helping 
with this text.

4) The scope of these address is smaller from global unicast address but 
larger than site-local.  They are scoped in a different manner than 
link-local, site-local, and global in that the scope of an individual /48 
prefix is created by a set of adhoc routing agreements and is not limited 
by the non-uniqueness of the prefix like site-local.

From a host's perspective this difference in scope shows up by different 
reachability than global unicast and could be handled by default that 
way.  It is probably better for nodes and applications to treat them 
differently from global unicast addresses.  A starting point might be to 
give them preference over global unicast, but fall back to global unicast 
if a particular destination is found to be unreachable.  Much of this 
behavior can be controlled by how they are allocated to nodes and put into 
the DNS.  However it is useful if a host can have both types of addresses 
and use them appropriately.  This creates a host with multiple global 
addresses, a form of multihoming.

Approaches to this problem have been proposed in drafts like 
 where a server is queried for the 
best source and destination address pair to reach a destination.  In the 
long term this approach might be combined with a DNS request where the 
request included all of the requesters source addresses that could be used 
and the resolver would return the preferred source and destination 
addresses.  This is, of course, not a trivial change to DNS but might be a 
reasonable approach to move forward in this area.

I would proposed that the IPv6 w.g. define the address format and default 
node and application behavior, and leave the more ambitious address 
selection solutions to multi6 or other working groups as appropriate.

I would appreciate your feedback and thoughts.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Misusing registries for uniqueness

[Bob Hinden]

I don't follow this.  It seems to me that there are two points on the 
allocation spectrum that are useful.  At one end there is a central 
registry for organizations that are willing to pay something and want some 
higher assurance of uniqueness (and a way to reconcile disputes).  At the 
other end is local generation of pseudo-random identifiers.  If people want 
to set up web sites that generate the pseudo-random numbers for this 
purpose, that is fine too.  I don't see any need for something in between 
the two approaches.  The value of a registry is to have a higher guarantee 
of uniqueness.  Other than that they should be generated locally.

Bob

At 02:36 PM 5/30/2003, Benny Amorsen wrote:
On 2003-05-30 at 11:09, Robert Elz wrote:

> Even adding in registries, as Benny Amorsen proposed, doesn't really
> solve the problems.  To be unique, there'd need to be one overall
> registry (perhaps sub-dividing the space to others) - which again means
> one monopoly, with no real justification for anyone to be the owner of
> that.
The advantage of using multiple registries is that the problems are
obvious to everyone. No one ends up thinking that their number is
guaranteed to be unique.
As you point out later, the addresses /cannot/ be enforced to be unique.
There were organisations which used 9/8 or 192/8 (not 192.168/16)
addresses for site local addressing in IPv4. An Internet Standard cannot
force people to comply.
I do not think there should be one top-level registry that subdivides
space to other registries. Rather I think each registry should pick
whatever bit of address space they feel like, within a single global
allocation for site-local addresses. If two registries pick the same
address space, too bad. Either they figure out a way to reconcile, or
customers will avoid them. If a registry takes too much space, the other
registries will ignore them.
Either way, anyone can set up their own registry of site-local IPv6
numbers. I think the working group should try to stay out of the fray,
except for setting aside a reasonably large space for it. A /16 would
seem appropriate.
Should site-local addresses end up not being standardised, there is
always 10/8 mapped with 6to4...
/Benny




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Draft on Globally Unique IPv6 Local Unicast Addresses

[Bob Hinden]

Brian,

At 04:22 AM 5/27/2003, Brian E Carpenter wrote:
Now, as a pragmatist, I would probably settle for a pseudo-random
and probably-unique /48, but not everybody will. I can just imagine a
phone call in which I recommend to IBM's chief network architect to use
address space that *probably* nobody else is using.
Do other people think we need a guaranteed-unique mechanism
for limited-scope addresses, or is probably-unique enough?
My take on the discussion is that we need both.  There are organizations 
who prefer to go to a registry to get some guarantee of uniqueness and 
others who prefer to generate a prefix themselves.

Your earlier suggestion of

I wouldn't have a problem with a variant of Bob's proposal in which
(for example) FC00::/8 is followed by a 40 bit ID allocated as Bob
suggests, and FD00::/8 is followed by a user-assigned 40 bit ID.
Then FC00::/7 would be the prefix for all limited-scope addresses.
appears to be a reasonable approach where the 40 bit ID under FD00:/8 would 
be selected by running an algorithm that would have to be specified.

There is a clear tradeoff between a longer ID (to allow for better random 
numbers or MAC addresses) and the size of the subnet field.

Before revising the draft, I would prefer to hear from more people on these 
tradeoffs.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Draft IPv6 Minutes from Atlanta IETF

[Bob Hinden]

Sorry, the subject should have been "Draft IPv6 Minutes from the San 
Francisco IETF".  The minutes are OK.

Bob

At 01:05 PM 3/28/2003, Bob Hinden wrote:
Draft IPv6 working group minutes from the San Francisco IETF are attached.

Please review and send comments.

Thanks,
Bob

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Draft IPv6 Minutes from Atlanta IETF

[Bob Hinden]

Draft IPv6 working group minutes from the San Francisco IETF are attached.

Please review and send comments.

Thanks,
BobIPv6 Working Group (ipv6) Agenda
IETF 56, San Francisco

CHAIRS:
Bob Hinden <[EMAIL PROTECTED]>
Margaret Wasserman <[EMAIL PROTECTED]>

Minutes notes taken: 
Bob Fink (March 17, 2003)
Christian Huitema (March 20, 2003)

AGENDA:

Introduction and Agenda Bashing -- Bob Hinden  (5 min)
Updated Charter -- Bob Hinden (10 min)
Working Group Action Plan -- Margaret Wasserman (15 min)
Prefix Delegation:
 - Prefix Delegation Requirements -- Shin Miyakawa (10 min)
 - DHCP Option for Prefix Delegation -- Ole Troan (5 min)
 - Moving forward on Proxy RA Approach -- Bob Hinden (5 min)
IPv6 MIBs -- Margaret Wasserman (10 min)
IPv6 Addressing Architecture Appeal:
 - Overview of IAB Response -- Leslie Daigle (20 min)
 - Working Group Response to Appeal Process -- Margaret Wasserman (10 min)
Access Control Prefix RA Option -- Steve Bellovin (10 min)
IPv6 Node Requirements, Open Issues -- John Loughney (30 min)
Analysis of IPv6 Anycast -- Itojun Hagino (10 min)

DHCPv6 DNS Resolver Configuration Option -- Ralph Droms (10 min)
IPv6 over Fibre Channel Review Request -- Claudio DeSanti (5 min)
IPv6 Addressing Architecture
 - Review of IAB Recommendations & Next Steps -- Margaret Wasserman (30 min) 
Node-Requirements follow up (10 min)
Site-Local Addressing -- Bob Hinden and Margaret Wasserman (60 min)
IPv6 Socket API for source address selection -- Erik Nordmark (10 min)

=
First Session:  Monday, March 17, 2003, 1930-2200
=

Introduction and Agenda Bashing -- Bob Hinden
-

Bob opened the meeting and reviewed the agenda. There were no changes to
the published agenda.

Updated Charter -- Bob Hinden
-



As discussed in Atlanta, except:
 DNS Discovery removed from the charter
  ADs instructed chairs to remove work item (an explanation sent to
  working group mailing list) 
  topic will be discussed at DNSOP session

Goal for end of year is to either re-charter or close wg.

Primary wg responsibilities are:
 Completing work on the IPv6 working group documents
 Reviewing and updating IPv6 specifications based on implementation and
 deployment experience,  and advancing them on the standardization track
 as appropriate. 

Hinden presented a list of urgent work items and a list of current work.


Action Plan -- Margaret Wasserman
-



Margaret Wasserman presented document status and related actions.

Bob Hinden thanked the authors of flow label draft.

Itojun asked what the status of the anycast analysis draft is.  Margaret
said not clear if it was part of the work of the wg yet.  Need to decide.


Prefix Delegation: Prefix Delegation Requirements -- Shin Miyakawa
--





Shin Miyakawa presented his work on prefix delegation requirements.

Shin noted that he appreciated the Michel Py and Pekka Savola
comments. Shin outlined them to see if there was agreement with going
ahead with the draft with Pekka's changes or not. Michel Py said he was
willing to go with the current text without changes for his comments.

Margaret asked what the wg thought of the changes.

Brian Haberman said layer two work out of scope. On lifetime he thinks it
should cascade down. The wg agreed.

Margaret asked how many people thought PPP be included, or should this
layer two stuff be removed. Christian thinks there is a difference
between a serial link and a shared link. So don't have to say PPP, but
must note the difference.

Dave Thaler thinks PPP and CHAP stuff should go away. Needs to be a
mechanism that works on a shared link. Also prioritization should be
removed.

Margaret asked if PPP and CHAP should be removed: unanimous to remove.

Margaret asked if the Layer 2 auth should be removed: unanimous generic
layer 2 auth stuff to stay.

Sentiment expressed there be a requirement for a solution that works on a
shared link.

Jordi Palet stated that it needs a shared link solution.

Hesham Soliman asked why this was more complex? Shin said PPoE employed
as it is easy to identify customer equipment.

Francis Dupont agreed with PPoE, but need a shared link solution.

Margaret asked if we need a prefix delegation solution on shared link:
consensus was that we need a solution that does.

Shin will modify the draft and get out for further review as soon as
possible.


DHCP Option for Prefix Delegation -- Ole Troan
--





Ole presented his DHCP option for prefix delegation.

He felt that it was ready for wg last call. There were no comments.


Moving forward on Proxy RA Approach -- Bob Hinden
-



Bob talked on Proxy RA solution. If

Re: RESEND: slides

[Bob Hinden]

Yes, they will be available on playground.sun.com/ipv6 and in the meeting 
proceedings.  I will try to get them on playground the week after the meeting.

Bob

At 09:25 AM 3/18/2003, [EMAIL PROTECTED] wrote:


> -Original Message-
> From: Ford,M,Mat,DEN5 FORDM5 R
> Sent: 17 March 2003 19:57
> To: '[EMAIL PROTECTED]'
> Subject: slides
>
>
> will the slides from today's meeting be made available somewhere?
>
> mat.
>

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Draft IPv6 working group charter

[Bob Hinden & Margaret Wasserman]

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 is responsible for the specification and
standardization of the Internet Protocol version 6 (IPv6).  IPv6 provides
a much larger global addresses space than its predecessor IPv4.  This
enables global end-to-end communication and restores valuable properties
of the IP architecture that have been lost in the IPv4 Internet.  The
core IPv6 standards are widely implemented and are in the early stages of
global deployment.

The IPv6 working group was originally chartered by the IESG as the IP
Next Generation (IPng) working group to implement the recommendations of
the IPng Area Directors as outlined at the July 1994 IETF meeting and in
"The Recommendation for the IP Next Generation Protocol," RFC1752,
January 1995.

The primary focus of the IPv6 w.g. is to complete the standardization of
the IPv6 protocols.

The working group's responsibilities are:

 - Completing work on the IPv6 working group documents as described
   below, and
 - Reviewing and updating IPv6 specifications based on implementation
   and deployment experience, and advancing them on the standardization
   track as appropriate.

The IPv6 working group's standardization responsibilities are divided
into two areas: Urgent for Deployment, and Completing Current Work.
Priority will be given to the first area.  The work items in each
priority area are as follows:

Urgent For Deployment
 - Complete Prefix Delegation requirements and publish.  Related work is:
o Work with DHCPv6 working group to write DHCPv6 option for IPv6
  prefix delegation.
o Develop Proxy Router Advertisement solution for prefix delegation
  and publish.  This enable a simple site border router to
  re-advertise downstream a prefix it hears on it's upstream link.
  Use Multi-Link subnet work as basis for this.  Note: general
  multi-link subnet work will be done elsewhere in the IETF.
 - Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and
   publish. 

Current Work
 - Complete work on "A Flexible method to manage the assignment of bits
   of an IPv6 address block".
 - Revise "Aggregatable Unicast Addresses" (RFC2374) to remove TLA/NLA/SLA 
   terminology. 
 - Revise "Basic Sockets Extensions" (RFC2553) and publish.
 - Revise "Advanced Sockets API" (RFC2292) and publish.
 - Complete "Default Router Preferences, More-Specific Routes, and Load
   Sharing" and publish.
 - Update to ICMPv6 (RFC2463) and publish.
 - Complete "Node Information Queries" and publish.
 - Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461)
   and publish.
 - Update "Privacy Extensions for Stateless Autoconfiguration"
   document (RFC3041) and publish.
 - Complete work on IPv6 Node Requirements and publish.
 - Complete work on Flow Label and publish.
 - Explore and document the issues with site-local addressing.  Determine
   appropriate limitations on the use of site-local addresses, and
   document those limitations.
 - Complete work on Scoped Addressing Architecture and publish.
 - Update IPv6 over PPP (RFC2472) and publish (may be done in PPP
   Extension w.g.). 
 - Review Point-to-point link support in IPv6 and decide if any IPv6
   specifications need to be updated.
 - Complete work on "Link Scoped IPv6 Multicast Addresses" and publish.

All new work items not listed above require the approval of the working
group and IESG before they will be taken on by the working group.

Goals & Milestones

Feb 03  Submit "A Flexible method to manage the assignment of bits
of an IPv6 address block" to the IESG for Informational.
Feb 03  Submit Flow Label specification to IESG for Proposed Standard.
Feb 03  Submit Routing Table MIB to IESG for Proposed Standard.
Mar 03  Submit Prefix Delegation requirements and submit to IESG for
Informational.
Mar 03  Draft on Proxy RA solution for prefix delegation.
Mar 03  Revise Aggregatable Unicast Addresses (RFC2374) to remove
TLA/NLA/SLA terminology. 
Apr 03  Submit update to ICMPv6 (RFC2463) to be republished at Draft
Standard.
Apr 03  Submit TCP MIB to IESG for Proposed Standard.
Apr 03  Submit IPv6 Node Requirements to IESG for Informational. 
May 03  Resubmit Node Information Queries to IESG for Proposed Standard.
May 03  Submit UDP MIB to IESG for Proposed Standard.
Jun 03  Submit IP MIB to IESG for Proposed Standard.
Jun 03  Submit Router Preferences, More-Specific Routes, and Load
Sharing to IESG for Proposed Standard
Jun 03  Submit updates to Auto Configuration (RFC2462) and Neighbor
Discovery (RFC2461) to be republished at Draft

Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-02.txt

[Bob Hinden]

I think the new draft resolves issues raised during the last call.  Changes 
to the document include:

 - Generalize the scope of the document to cover more than the 2000::/3
   prefix.  This includes changing the title and introduction text.
 - Added a new section that describes in more detail why the TLA/NLA structure
   is being made historic.
 - Including an example of the address format that is consistent with
   the recommendations in RFC3177.
 - Added Erik Nordmark as an author (note this is not shown in the
   ID announcement).
 - Clarified normative and non-normative references.
 - Various small improvements to the text.
I think the consensus of the discussion was to advance this document as in 
Informational RFC instead of to Proposed Standard.  I believe it is now 
ready to be sent to the IESG.

Bob

At 04:28 AM 3/4/2003, [EMAIL PROTECTED] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP Version 6 Working Group Working Group 
of the IETF.

Title   : IPv6 Global Unicast Address Format
Author(s)   : R. Hinden, S. Deering
Filename: draft-ietf-ipv6-unicast-aggr-v2-02.txt
Pages   : 5
Date: 2003-3-3
RFC2374 'An IPv6 Aggregatable Global Unicast Address Format' defined
an IPv6 address allocation structure that includes TLA (Top Level
Aggregator) and NLA (Next Level Aggregator).  This document replaces
RFC2374, and makes RFC 2374 and the TLA/NLA structure historic.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt
To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipv6-unicast-aggr-v2-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt".
NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipv6-unicast-aggr-v2-02.txt


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "IPv6 Flow Label Specification"

[Bob Hinden & Margaret Wasserman]

This is a one week IPv6 working group last call for comments on advancing 
the following document as a Proposed Standard:

Title   : IPv6 Flow Label Specification
Author(s)   : J. Rajahalme, A. Conta, B. Carpenter, S. Deering
Filename: draft-ietf-ipv6-flow-label-05.txt
Pages   : 8
Date: 2003-3-3
The chairs belive this draft represents the consensus of the working group 
and resolves issues raised during and subsequent to the working group last 
call.  However given the time that has elapsed we think a short 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


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

DRAFT: Agenda Announcement

[Bob Hinden & Margaret Wasserman]

The IPv6 working group has two session at the San Francisco IETF 
meeting.  They are:

   MONDAY, March 17, 2003, 1930-2200
   THURSDAY, March 20, 2003, 0900-1130
There are several important topics to which we will devote significant 
meeting time.

  - Node Requirements
  - Prefix Delegation
  - Site-Local Usage
 o Impact of Site-Local draft
 o Moderate Use Case draft
  - MIB Updates
Please send us requests for agenda items.  We will be giving priority to 
the above topics, but will fit other things in as time allows.  For this we 
will give preference to current working group 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://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Follow up to IAB response to Robert Elz's Appeal

[Bob Hinden & Margaret Wasserman]

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 working group chairs
Date: Tue, 25 Feb 2003 16:01:09 -0800
To: [EMAIL PROTECTED]
From: Bob Hinden <[EMAIL PROTECTED]>
Subject: Follow up to IAB response to Robert Elz's Appeal
Sender: [EMAIL PROTECTED]
The IAB has responded to an appeal from Robert Elz of the IESG decision
to approve the IPv6 Addressing Architecture 
(draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document 
should not be published as a Draft Standard [1].  Given that the revised 
document is a significant improvement over RFC 2473, and that RFC2473 is 
badly out of date, we believe it is desirable to go ahead and publish the 
document as a Proposed Standard at this time ASAP in order to get a 
replacement to RFC2473 out.

In parallel, it would be appropriate to discuss the details of the IAB 
response and how the WG wishes to respond to the IAB 
recommendations.  Note that approving the document as PS at this time does 
not imply that the WG agrees with all of the IAB's recommendations nor 
does it preclude any particular follow-on action by the WG or 
IESG.  However, approval at PS is something that can be done relatively 
quickly.

Does this approach make sense to the WG?

Bob Hinden, Margaret Wasserman; IPv6 Chairs
Thomas Narten, Erik Nordmark; Internet ADs
[1] IAB, "Re: Appeal against IESG decision",
http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Request to Advance "Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block"

[Bob Hinden & Margaret Wasserman]

Erik, Thomas,

The chairs of the IPv6 working group, on behalf of the working group, 
request that the following document be published as an Informational RFC:

Title   : A Flexible Method for Managing the Assignment of
 Bits of an IPv6 Address Block
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

IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Follow up to IAB response to Robert Elz's Appeal

[Bob Hinden]

The IAB has responded to an appeal from Robert Elz of the IESG decision
to approve the IPv6 Addressing Architecture 
(draft-ietf-ipngwg-addr-arch-v3-11.txt) by indicating that the document 
should not be published as a Draft Standard [1].  Given that the revised 
document is a significant improvement over RFC 2473, and that RFC2473 is 
badly out of date, we believe it is desirable to go ahead and publish the 
document as a Proposed Standard at this time ASAP in order to get a 
replacement to RFC2473 out.

In parallel, it would be appropriate to discuss the details of the IAB 
response and how the WG wishes to respond to the IAB recommendations.  Note 
that approving the document as PS at this time does not imply that the WG 
agrees with all of the IAB's recommendations nor does it preclude any 
particular follow-on action by the WG or IESG.  However, approval at PS is 
something that can be done relatively quickly.

Does this approach make sense to the WG?

Bob Hinden, Margaret Wasserman; IPv6 Chairs
Thomas Narten, Erik Nordmark; Internet ADs
[1] IAB, "Re: Appeal against IESG decision",
http://www.iab.org/Appeals/kre-ipng-address-arch-draft-standard-response.html 


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

[Bob Hinden]

I still do not (yet) see the need for further clarifications in the
documents (and certainly not in node requirements, for the level of
detail we're talking about here).
My view as well.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"

[Bob Hinden]

Erik,


> Care to suggest some text?

RFC 2374 contained an IPv6 allocation structure that included
TLA (Top Level Aggregator) and NLA (Next Level Aggregator) which
is formally made historic by this document.

The TLA/NLA scheme has been replaced by an coordinated allocation 
policy
defined by the Regional Internet Registries [REF].

Part of the motivations for obsoleting the TLA/NLA structure
were technical, for instance there was concerns that it was not
the technically best approach at this point in time on IPv6 
deployment.
Another part of the motivation was that the issues of how the
IPv6 address space is managed is much more related to policy and
to the the stewardship of the IP address space and routing table
size that the RIRs have been managing for IPv4. It is likely that
the RIRs policy will evolve as IPv6 deployment proceeds.

The IETF has provided technical input to the RIRs
(for example [RFC 3177]) that has been taken into account
when defining the policy.

This is OK for me.  I will plan add it to the next version of the 
draft.  Would you like to be listed as an author?

Any one else have comments on this change?


> >Because this might confuse people that they should only code for 2000::/3
> >in their implementation?
>
> I don't see how one could come to this conclusion.
>
> The draft was written to only cover the 2000::/3 prefix because the
> document it is obsoleting also only covers that prefix.  For example from
> section 2.0 of RFC2374:

I agree that RFC 2374 only covers that prefix.
But that doesn't mean that the docment which makes 2374 historic
needs to have the same limitation.


> What did you have in mind that might further clarify this issue?

Remove "for the 2000::/3 Prefix" from the title and remove
the mention of the specific prefix from the text.


OK, that is clearer.  It wouldn't be too hard to make this change, but 
there doesn't seem to be complete agreement on the list for this change.

Apart from the restriction to 2000::/3 I don't see how section 2.0 adds
anything beyond what is in addr-arch. Perhaps I'm missing something.


I think it provides a summary of what the resulting address format for this 
prefix (and other prefixes if the above change is made).  Since we now seem 
to heading toward a non-standards track document, what is the harm?

> While I don't feel too strongly about that status of the document, I share
> the belief that is important to send a "strong" message.  Perhaps
> classifying it as a BCP might be a good middle ground.

But the strong message would be that there would be an IETF last call
saying that RFC 2374 is moving to historic and this doc informational.
Then this will be permanently recorded in rfc-index with 2374 being marked
as historic.

This seems to be strong enough for other protocols/documents we've made
historic such as RIPv1 (with RFC 1923 being the info doc that explains
why).


The RIPv1/v2 case seems fairly different to me, because the RIPv2 existed 
for a long time before RIPv1 was made historic.

I now agree that it can be non-standards track.  What was your objection to 
making it a BCP?  In some ways this is the best current practice.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

RE: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt

[Bob Hinden]

I agree with this and think that a MUST for stateless and MAY for DHCP is 
fine.

Bob (with no hats on)

We had a conclusive discussion off this point during the interim WG
meeting in Sunnyvale. The reasoning goes as follow: if we want to
maximize interoperability, we want to have a single mandatory address
configuration procedure, not two; everybody agrees that we must support
stateless address configuration; thus we should make stateless
mandatory, and other configuration methods optional.

This is properly reflected in section 5.3 (nodes MAY support DHCPv6), in
section 4.5.2 (MUST support stateless) and in the current text of
section 4.5.5, which is just fine.

-- Christian Huitema



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 WG Last Call on "IPv6 Global Unicast Address Format for the 2000::/3 Prefix"

[Bob Hinden]

Erik,

At 09:05 AM 2/12/2003, Erik Nordmark wrote:

> I agree with Michel. Although Thomas is logically correct,
> I think that including section 2.0 and putting this on
> standards track is a necessary signal to ensure that TLAs
> are really understood to be dead.


I too agree with this view.  I tried to write this draft to be as 
uncontroversial as possible so it could proceed quickly and accomplish the 
goal of replacing RFC2374.

If you want to be explicit about TLA/NLA being dead why not have
a section 2.0 titled "TLA and NLA are dead"
with a shortish explanation of why and with an informational reference
to the registries document?


Care to suggest some text?


> I also think the explicit reference to 2000::/3 is useful.
> It's the only space currently being allocated.

Because this might confuse people that they should only code for 2000::/3
in their implementation?


I don't see how one could come to this conclusion.

The draft was written to only cover the 2000::/3 prefix because the 
document it is obsoleting also only covers that prefix.  For example from 
section 2.0 of RFC2374:

   This document defines an address format for the 001 (binary) Format
   Prefix for Aggregatable Global Unicast addresses. The same address
   format could be used for other Format Prefixes, as long as these
   Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
   Format Prefix is defined here.

Making it apply to other prefixes seemed out of scope to me.

We tried to make this clear in addr-arch-v3 (hopefully clear enough) but
this document is not clear enough on that issue.


What did you have in mind that might further clarify this issue?


Since RFCs live forever the "currently being allocated" argument might
not be a good argument.


Finally, assuming that this document isn't going standardize anything
(now that the documentation prefix is removed) I think it makes
sense having be an informational document that is part of a protocol
action which moves RFC 2374 to historic.
Only if this document standardizes some replacement to 2374 would it make
sense for it to be proposed standard.

Examples of "move to historic" documents are RFC 3197 and RFC 3167.
They tend to explain why and what is being made historic with varying levels
of detail.


While I don't feel too strongly about that status of the document, I share 
the belief that is important to send a "strong" message.  Perhaps 
classifying it as a BCP might be a good middle ground.

Bob



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-01.txt

[Bob Hinden]

I have made a request (as the author) to the other co-chair to start a w.g. 
last call.

Bob

At 04:23 AM 2/7/2003, Brian E Carpenter wrote:
Pekka Savola wrote:
>
> On Thu, 6 Feb 2003, Michel Py wrote:
> > I say, ship it.
>
> Agree.

I say, WG Last Call it right away, so that it can be with the IESG
before the IETF.

   Brian



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Documentation Prefix

[Bob Hinden]

Alain,


There are some unanswered questions about this APNIC prefix:
1- Can people who are not member of APNIC use this prefix?


I don't see why not as it isn't supposed to be routed.


2- How do people who are not APNIC members know about this prefix?
i.e. how an implementor familiar with the RFC series but unaware
of APNIC documents will know that such a prefix has been reserved?


Good question.  I wasn't aware of it until Patrick Grossetete pointed it 
out to me.

3- What about the other RIRs? Are they going to recommend to use
this prefix or are they going to reserve some others?


I would hope there would only be one assignment by the RIRs.  It would be 
ironic if after all this time of trying to get a prefix for documentation, 
we get several :-)

Perhaps a separate very short Informatinal RFC pointing to
a common RIR policy (once/if established) will help.


I will forward you email to Paul Wilson at APNIC.  I think that what APNIC 
did was well intended, it might have been better if the IANA had done the 
allocation as it is not a regional issue and it might have been better to 
pick a prefix that was not in the middle of other assignments.

Thanks,
Bob



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Documentation Prefix

[Bob Hinden]

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 from 
 and submit a new draft.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt

[Bob Hinden]

Pekka,


> Thanks.

Oh, btw, in the references too.


At least I was consistent :-)


> It seemed to me like a convenient place to do it as this was defining the
> 2000::/3 prefix.  It could be done elsewhere, but hopefully this draft can
> get through the process quickly.

Well, if one believes this can be done quickly here, no problem.


I was hoping this would be the case.


But I'm not sure it can.

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 2001:::/32.


I viewed it as opening up the rest of the 2000::/16 prefix for /32 
allocations.  Currently all of 2000::/16 is reserved in

  http://www.iana.org/assignments/ipv6-tla-assignments

I guess it depends on how one looks at it.

And this kind of "which one is the right block to reserve" discussions
could delay the other parts of the draft, which was my main motivation for
keeping it outside of this one.


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.

> >5.0 References
> >
> >==> split the references.
>
> Why?  Most are normative or very static.

Because otherwise the draft will get bounced back when the AD checks for
ID-nits, and because it's required before it can get to the RFC editor..


For practical purposes they are all normative.  It if helps, I can say that 
in the next version of the draft.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt

[Bob Hinden]

I will agree with Alain that a reserved prefix for documentation is
good. But, I don't understand why '2000:0001::/32" was chosen instead
of '2000:::/32'. Can someone speak to this?


The tradition that I learned from John Postel of always reserving the 
beginning and end of any address space and is consistent with:

  http://www.iana.org/assignments/ipv6-tla-assignments

It also looks like a real assignment.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: I-D ACTION:draft-ietf-ipv6-unicast-aggr-v2-00.txt

[Bob Hinden]

Pekka,


draft-ietf-ipv6-unicast-aggr-v2-00.txt

==> how did the first draft suddently jump to a w.g. document?  I don't
recall this question being raised, unless it was years ago (or I've missed
something).  Not that I disagree with (most of) the contents, but some
parts at least seem to be questionable.


It's been in the works for a while and is in the current and proposed 
charter.  The current charter has:

 - Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the
   policy aspects that are considered RIR issues.

Issuing this draft now was a follow up to the IPv6 Address Architecture 
being approved as a Draft Standard.

   This document defines the unicast address format for the 2000::/3
   (001 binary) prefix.  The address format defined in this document is
   consistent with RFC1883 "Internet Protocol, Version 6 (IPv6)
   Specification"

==> s/1883/2460/


Thanks.


   The specific format of global unicast address under the 2000::/3
   prefix is:

  | 3 | n bits | 61-n bits |   64 bits  |
  +---++---++
  |001|  routing prefix| subnet ID |   interface ID |
  +---++---++

==> I guess this is another part which some folks will just ignore .. but
no matter.

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 the use of the full
2000::/16 for something else.


See other responses.  There has been a request for the reservation of some 
IPv6 address space for documentation.

I'd rather reserve a documentation prefix somewhere else, and in some
other, _separate_ internet-draft.


It seemed to me like a convenient place to do it as this was defining the 
2000::/3 prefix.  It could be done elsewhere, but hopefully this draft can 
get through the process quickly.

5.0 References

==> split the references.


Why?  Most are normative or very static.

Thanks,
Bob



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "IP Forwarding Table MIB"

[Bob Hinden]

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

	Title		: IP Forwarding Table MIB
	Author(s)	: M. Wasserman
	Filename	: draft-ietf-ipv6-rfc2096-update-02.txt
	Pages		: 30
	Date		: 2002-11-7

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the document editor.  This last call period will end 
on January 30, 2003.

Bob Hinden


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "A Flexible Method for Managing the Assignment of Bytes of an IPv6 Address Block"

[Bob Hinden & Margaret Wasserman]

This is a IPv6 working group last call for comments on advancing the 
following document as an Informational RFC:

	Title		: A Flexible Method for Managing the Assignment of
 Bits of an IPv6 Address Block
	Author(s)	: M. Blanchet
	Filename	: draft-ietf-ipv6-ipaddressassign-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 IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

I-D ACTION:draft-hinden-ipv6-sl-moderate-00.txt

[by way of Bob Hinden <[EMAIL PROTECTED]>]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Moderate Use Case for IPv6 Site-Local Addresses
	Author(s)	: R. Hinden
	Filename	: draft-hinden-ipv6-sl-moderate-00.txt
	Pages		: 7
	Date		: 2003-1-7
	
This internet draft describes the moderate use case for IPv6 Site-
Local Addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-sl-moderate-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hinden-ipv6-sl-moderate-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[EMAIL PROTECTED]
In the body type:
	"FILE /internet-drafts/draft-hinden-ipv6-sl-moderate-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[EMAIL PROTECTED]>

ENCODING mime
FILE /internet-drafts/draft-hinden-ipv6-sl-moderate-00.txt




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Moderate Site-Local Usage Draft

[Bob Hinden]

Hiroki,


>   The motivation for this use case is to restrict the use of site-local
>   addresses to communication inside of the site and insure that they
>   are less likely to be used for any site to site communication.

I cannot understand what this sentence means.  I believe that any
site-to-site communication is supposed to be done via global addresses.
Site local addresses MUST not be used for inter-site communication.
Or am I misunderstanding?


That is what the draft is trying to say.  The draft is attempting to define 
rules/guidelines that insure that site-local addresses will not be used for 
site to site (inter-site) communications.

>   Using limited scope addresses for site to site communication, while
>   possible (i.e., via tunneling or VPN technologies), is problematic
>   and makes it hard to debug problems.  Overall it is simpler to use
>   global addresses.

Does it include configured IPv6-over-IPv4 tunnels?
Many IPv6 networks are built using IPv6-over-IPv4 tunnels.


This is a good point to cover.  I think the answer depends on what is being 
connected with IPv6-over-IPv4 tunnels.  Is a single site?  If not, then 
site-local addresses should not be used.

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).


Thanks.  The draft attempts to define a use case where site-locals are only 
used where specifically configured.  This will permit their use for 
situations where the site desires to use them, but limit their use otherwise.

Personally, I would like to have Margaret's
draft-wasserman-ipv6-sl-impact-00.txt as a document on the issues
associated with site-local addressing (w/o recommendations section)
and Bob's draft-hinden-ipv6-sl-moderate-00.txt as a site-local usage
document.  I know that many people have different opinions. :-)


That would be a reasonable approach.  Yes, opinion do vary on this topic!


Thank you and A Happy New Year,


Happy New Year,
Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Moderate Site-Local Usage Draft

[Bob Hinden]

I submitted a draft on the moderate use case for IPv6 site-local addresses.

Since the ID folks are on vacation until January 6, 2003, you can find a 
copy at:

  http://playground.sun.com/ipng/doc/draft-hinden-ipv6-sl-moderate-00.txt

Comments appreciated.

Thanks and Happy New Year!

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: draft-hinden-ipv6-global-site-local-00.txt

[Bob Hinden]

Keith,


operationally I think it would be a mess to have site-locals routed
differently within a site than globals.  it's not that you can't do it,
it's that it makes life more difficult, and GUPIs seem to be a better
way to solve the same problem.


I am not sure there is that much difference.  In the current /48 provider 
based global addresses, each subnet is identified by a /64 prefix.  Both 
approaches will generate /64 routes.  I suspect that only in the largest 
sites, will the subnet field also be used for aggregation inside of the site.

This is all about tradeoffs.  For example in the site-local prefix 
FEC0::/10, there are 54-bits available for global identification and subnet 
numbering.  If 16-bits are for subnets, then there are 38-bits left for 
global site identification.  Is this big enough for a global 
token?  Probably not if it a random number or based on some other existing 
global identifier.  Might be OK if it was centrally allocated, but who is 
going to do that?  Also, what about sites that need more than 16-bits of 
subnets?

We could use a shorter prefix, but how much of the total IPv6 address space 
do we want to use for this?  For example, a /2 prefix would allow 16-bits 
of subnets and a 46-bit token.  But this would use 1/4 of the total IPv6 
address space.  That doesn't seem wise.

So I am not sure there is any solution that has the three properties:

 1) globally unique
 2) 16-bit subnet field
 3) Uses a limited amount of the IPv6 address space

We may have to pick the two we think are the most important.  The current 
site-local definition has 2) and 3).  My global site local proposal has 1) 
and 3).  Andrew White's draft has 1) and 3).

Bob





IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Enforcing unreachability of site local addresses

[Bob Hinden]

Margaret,


In my opinion, the only way that we will stop people from using NAT
(with or without IPv6 site-local addresses) will be to provider better
(architecturally cleaner, more convenient, more functional) mechanisms
for people to get the same benefits that they get from NATs today.
Although NATs may have started as a response to address space shortage,
today their use is driven by the needs for provider-independent addressing
and convenient access control.  So, we need to work on better ways to
provide those things in IPv6.


I am not sure that this is really true.  When I was looking for a new DSL 
provider I found that in many cases I could get service at a specific 
bandwidth with a singe address for about $60 a month.  If I wanted a /29 
instead, it would cost about $30 more a month.  50% more for 6 usable 
addresses!  I think this is fairly common.  The lower cost DSL providers 
doen't even give the user to choice to get more addresses.  People are 
still being forced to run NAT in response to address scarcity.  We could 
only tell for sure if people would still run NAT for other reasons if 
addresses were readily available.

I ended up finding a different ISP who charged more money, but gave me more 
bandwidth and the addresses I wanted.  Most people would not be willing to 
do that and would be forced to run NAT.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: draft-hinden-ipv6-global-site-local-00.txt

[Bob Hinden]

Keith, Brian,

At 02:06 AM 12/11/2002, Brian E Carpenter wrote:

For the record, I am still completely against any proposal
that takes over the normal 16 bit subnet field, i.e.
generates a prefix longer than /48. It just isn't
operationally convenient.


At 04:12 PM 12/11/2002, Keith Moore wrote:

> I'm still unsure about this insistence on /48 as a critical point of
> allocation.

renumbering is a lot more painful if you're trying to renumber
between prefixes of different lengths.


Ignoring the area field (that I am starting to think was a mistake) for a 
minute, the idea in the draft is that one could have site-local prefixes 
that are independent from the global prefixes and would not have to be 
renumbered.  Because they are globally unique they would survive site 
joining and/or splitting, change of ISP, change of topology, etc.  There 
were not intended to be used in the same manner as the global prefixes that 
have a 16-bit subnet field.

The cost for this flexibility was that they had to be flat routed in the 
site.  I think that is a good tradeoff, but opinions will vary.

Bob



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: "unique enough" [RE: globally unique site local addresses]

[Bob Hinden]

Keith,

I think your points on both topics are well taken.

I also have the notion that the current approach of combining the locator 
and identifier in IPv4 and IPv6 has a lot of value that we tend to take for 
granted.  It provides a degree of authentication that requires lots of 
cryptographic technology to replicate if they are separated.  Instead of a 
bug, I think it is a feature :-)

Bob

a true separation of locator and identifier is a more fundamental
change to the Internet architecture than moving from IPv4 to IPv6.

as soon as you separate locator and identifier,  you have the burden of
providing a mapping service between the two, which is efficient,
reliable, secure, and precise enough to be used for all applications.
DNS (which is typically proposed as the solution) doesn't even come close.

OTOH, mobileIP is a fairly close approximation to separating locator
and identifier if you get past the notion that "home agent" is specific
to a single host (as opposed to a set of hosts with a common prefix),
and that "home" has anything to do with the normal physical location of
a host.  being able to get rid of the home agent when the host has a
home and is at home is a useful optimization that works in some cases,
but not in all or most cases.



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: draft-hinden-ipv6-global-site-local-00.txt

[Bob Hinden]

Mark,

At 05:54 PM 12/9/2002, Mark Smith wrote:

Hi Bob,

A few thoughts / questions / comments on your draft :

3.0 Proposal & 3.1 Global Token

* 8 bit areas

I'm curious as to why you chose to allocate 8 bits for the area.

Allocating 6 bits for area would allow aggregation to take place on the
/16 bit boundary. I think this would make it a easier for network admins
to manage their site-local area prefixes when bounded at /16.

I was going to suggest putting back the u and g bits, which would make
connecting to the origin router for this prefix easier (just telnet to
fec0 + EUI-64 + EUI-64), but then realised that your site local global
token is generated from an EUI-48 :-(

I think there probably is some value in keeping the full EUI-48 as the
global token for trouble shooting reasons, at the sacrifice of 2 area
bits.


I was trying to see how many bits I could have left over and still use the 
EUI-48 as the basis for the global token.  I think I agree that it would be 
simpler just using the whole 48-bits and shrink the area.

3.2 Assignment

* maybe be a bit more explicit about how manual configuration is
achieved.

I agree with and understand the motivation for manual assignment of
these prefixes.

However, the whole proposal has a strong "auto-configuration" theme -
deriving site-local addresses from EUI-48s sounds a lot like something
that would be done automatically by default.


I agree.  I think one of the good things about this approach is that could 
be made to auto-configure the subnets.  I wasn't attempting to solve all of 
the issues to make that work in this draft.

Would a typical implementation of this manual assignment be a toggle
switch / [on / off] configuration option within a router ?



If so, additional text suggesting that these prefixes will be
automatically generated, but manually enabled / disabled (defaulted to
disabled) might help overcome the "auto-configuration" theme of the
generation of these prefixes.


I agree adding some text to clarify how this could work would make it 
clearer.  Semi-automatic might be a good way to describe it.  The 
administrator could be give a choice of creating a prefix based in the 
interfaces EUI-48 address, enter a global token, or use a prefix it has 
heard advertised from another router.  This would make the installation of 
the routers fairly simple and in most cases avoid typing in big strings of 
digits.

* the term "area" might be a bit vague, in the sense that usually people
talk about "areas", they are referring to OSPF areas.

I found when I initially read this term, I immediately wondered whether
this field has some use or value wrt OSPF.


The use of area was not coincidental.  I was thinking about OSPF areas as 
that is probably about the right size to flat route a number of subnets.

A different name for this field might be a bit less confusing.

- I don't feel that strongly on this, I think it is just that "area" is
in such common usage in the OSPF context (and to my knowledge, no where
is in IP routing / addressing), most people would immediately associate
any usage of the term "area" in an RFC with OSPF.


Another question is the area field that useful or would it be better to 
just have /64 prefixes and flat route them in a site.  This might make the 
proposal simpler and better.  On the other hand, it is nice to have a way 
of scaling the routing protocol inside the site.

Thoughts?

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Retail IPv6 Service in the US?

[Bob Hinden]

Bill,


demand.  So the near-term, pragmatic tactic seems to be for
us small users to vote w/ our pocketbooks and support the regional/local
ISPs that support IPv6 to local exchanges.


I think the expression is "think globally, act locally".  Don't wait for 
someone else to do it.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Retail IPv6 Service in the US?

[Bob Hinden]

James,

At 10:21 AM 12/11/2002, James Kempf wrote:

I'm in the process of upgrading my home computing infrastructure in order 
to be
able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6
service (specifically, in the SF Bay Area)?

I did a quick Google search and all the offerings seem to be for backbone
service.

I am unfortunately, also working on this.  I used to have DSL service from 
a local provider, but they discontinued it abruptly a week and a half 
ago.  Until they shut it down, I had IPv6 service with a configured tunnel 
to nokia.net with a /48 assignment.

I found a new local SF bay area provider, meer.net, and signed up with 
them.  They expressed some interest in later offering IPv6 service.  [Note, 
I don't have any personal financial interest in meer.net so I am only 
mentioning them on the list because of their interest in IPv6.]  Once the 
new DSL line is up, I will setup the configured tunnel again.  I was 
planning on working with meer.net to help them get IPv6 running so I could 
get rid of the tunnel.

If you contact them, suggest you mention your interest in IPv6.  If enough 
people ask for it

Bob





IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: draft-hinden-ipv6-global-site-local-00.txt

[Bob Hinden]

Alain,

At 02:10 PM 12/9/2002, Alain Durand wrote:

This proposal is making the assumption that MAC addreses are somehow stable.
I think this is a bad idea.


MAC addresses are stable.  What may not be stable is their life in on an 
interface in a specific machine.  The words in the draft are:

   3.2 Assignment

   The globally unique site-local prefixes defined in this document are
   intended to be manually assigned to router interfaces in a site.  The
   global token used in each prefix would be created from an EUI-48
   address found in an interface on the subnet.

There is no requirement that this be the same as the routers interface nor 
is it required to be automatic.

MAC addresses were selected as a source of global token because they are 
good global token.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

I-D ACTION:draft-hinden-ipv6-global-site-local-00.txt

[by way of Bob Hinden <[EMAIL PROTECTED]>]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: IPv6 Globally Unique Site-Local Addresses
	Author(s)	: R. Hinden
	Filename	: draft-hinden-ipv6-global-site-local-00.txt
	Pages		: 7
	Date		: 2002-12-6
	
This internet draft describes a proposal for IPv6 Globally Unique
Site-Local Addresses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-site-local-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hinden-ipv6-global-site-local-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[EMAIL PROTECTED]
In the body type:
	"FILE /internet-drafts/draft-hinden-ipv6-global-site-local-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Content-Type: text/plain
Content-ID:	<[EMAIL PROTECTED]>

ENCODING mime
FILE /internet-drafts/draft-hinden-ipv6-global-site-local-00.txt




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: Enforcing unreachability of site local addresses

[Bob Hinden]

Margaret,


Bob, are you or anyone else working to document the "moderate usage"
proposal?


Yes, I am working on a "moderate usage" draft.

Bob



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: EUI-48 globally unique site-locals (GUSL)

[Bob Hinden]

Aidan,


For each link, a router may automatically assign a site-local
address from an EUI-48 (ie a MAC address) using the following
address format:

   | 12 bits | 48 bits  |  4 bits  |   64 bits|
   +-+--+--+--+
   |   fef   | router device ID |  sub ID  | machine interface ID |
   +-+--+--+--+
  Figure 1: Address Format: fef0::/12


BTW, two bits in an EUI-48 (i.e., the g and u bits) are not needed if using 
this as a global token, so it could be easily compressed to 46 bits leaving 
two more bits for the subnet.

I am not sure this helps very much with the other problems raised.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

ATTENTION: Use of the ipng mailing list

[Bob Hinden & Margaret Wasserman]

Hi All,

We appreciate the enthusiasm that several of you have shown regarding the 
previous site-local discussion and the current discussion of 
globally-unique, provider-independent addresses. However, these discussions 
are not an effective way to use our mailing list.

There is a limit to the amount of mail that most people can reasonably 
handle, and it is likely that most members of the IPv6 working group have 
been unable to follow these discussions or get much value from them.  No 
useful consensus can be drawn from such discussions.

In order to increase the quality and productivity of our mailing list 
discussions, we would ask people to do the following:

- Self-limit the rate of your postings to the list.
  Please read to the bottom of the thread before
  responding, think about the points you want
  to make, and avoid making the same points repeatedly.
		
- Please submit individual Internet-Drafts that describe
  proposed solutions and/or make cases for or
  against the topic at hand.  This is a much
  more effective than e-mail as a way to discuss
  complex topics and reach consensus.

- Notice when circular discussions are happening
  between a small group of people and stop.
  Rough consensus is not determined or affected
  by who has the last word on a topic, and no
  WG consensus can be drawn from a discussion
  among a small group of people.
		
These steps should help to make our mailing list more useful and productive 
for the entire WG, and your voluntary cooperation is appreciated.  If 
excessive behavior continues, we will contact individuals privately to 
discuss the problems and how to correct them.

Thanks,
Margaret Wasserman & Bob Hinden
IPv6 WG Chairs








IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

test, please ignore

[Bob Hinden]

test, please ignore


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Proposed IPv6 W.G. Charter Update

[Bob Hinden]

Attached is a proposed update to the IPv6 working group charter.  This will 
be discussed at the IPv6 session tonight at IETF55 and on the mailing list.

Please comment on the list and at tonights session.

Bob Hinden and Margaret Wasserman
IPv6 chairsInternet Protocol Version 6 (IPv6) Working Group Charter -- DRAFT 



Chairs:

Bob Hinden <[EMAIL PROTECTED]>
Margaret Wasserman <[EMAIL PROTECTED]>

Chair Emeritus:

Steve Deering <[EMAIL PROTECTED]>

Document Editor:

Bob Hinden <[EMAIL PROTECTED]>


Description of the Working Group:

The IPv6 working group is responsible for the specification and
standardization of the Internet Protocol version 6 (IPv6).  IPv6 provides
a much larger global addresses space than it predecessor IPv4.  This
enables global end-to-end communication and restores valuable properties
of the IP architecture that have been lost in the IPv4 Internet.  The
core IPv6 standards are widely implemented and are in the early stages of
global deployment.

The IPv6 working group was originally chartered by the IESG as the IP
Next Generation (IPng) working group to implement the recommendations of
the IPng Area Directors as outlined at the July 1994 IETF meeting and in
"The Recommendation for the IP Next Generation Protocol," RFC1752,
January 1995.

The primary focus of the IPv6 w.g. is to complete the standardization of
the IPv6 protocols.

The working group's responsibilities are:

 - Complete work on the IPv6 working group documents as described
   below.  
 - Reviewing and updating IPv6 specifications based on implementation
   and deployment experience, and advancing them on the standardization
   track as appropriate.

The IPv6 working group's standardization responsibilities are divided
into two areas: Urgent for Deployment, and Completing Current Work.
Priority will be given to the first area.  The work items in each
priority area are as follows:

Urgent For Deployment
 - Complete work on DNS Resolver Address Auto-configuration and publish.
 - Complete Prefix Delegation requirements and publish.  Related work is:
o Work with DHCPv6 working group to write DHCPv6 option for IPv6
  prefix delegation.
o Develop Proxy Router Advertisement solution for prefix delegation
  and publish.  This enable a simple site border router to
  re-advertise downstream a prefix it hears on it's upstream link.
 - Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and
   publish. 

Current Work
 - Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA 
   terminology. 
 - Revise Basic Sockets Extensions (RFC2553) and publish.
 - Revise Advanced Sockets API (RFC2292) and publish.
 - Complete Default Router Preferences, More-Specific Routes, and Load
   Sharing and publish.
 - Update to ICMPv6 (RFC2463) and publish.
 - Complete Node Information Queries and publish.
 - Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461)
   and publish.
 - Update Privacy Extensions for Stateless Autoconfiguration
   document (RFC3041) and publish.
 - Complete work on IPv6 Node Requirements and publish.
 - Complete work on Flow Label and publish.
 - Complete work on Scoped Addressing Architecture and publish.
 - Update IPv6 over PPP (RFC2023) and publish (may be done in PPP
   Extension w.g.). 
 - Review Point-to-point link support in IPv6 and decide if any IPv6
   specifications need to be updated. 

All new work items not listed above require the approval of the working
group and IESG before they will be taken on by the working group.

Goals & Milestones

Nov 02  Submit DNS Resolver Address Auto-configuration draft to IESG for
Proposed Standard 
Nov 02  Submit Prefix Delegation requirements and submit to IESG for
Informational
Dec 02  Submit update to ICMPv6 (RFC2463) to be republished at Draft
Standard. 
Mar 03  Resubmit Node Information Queries to IESG for Proposed Standard.
Jan 03  Submit DHCPv6 option for IPv6 prefix delegation to the IESG for
Proposed standard.  Note this milestone may be done by DHC
working group.
Jan 03  Draft on Proxy RA solution
Jan 03  Submit Flow Label specification to IESG for Proposed Standard.
Mar 03  Submit Proxy RA draft and submit to IESG for Proposed Standard.
Mar 03  Submit revision  of IPv6 MIBs (combined IPv4/IPv6 versions) to
IESG for Proposed Standard.
Mar 03  Revise Aggregatable Unicast Addresses (RFC2374) to remove
TLA/NLA/SLA terminology. 
Apr 03  Submit IPv6 Node Requirements to IESG for Informational. 
Jun 03  Submit Router Preferences, More-Specific Routes, and Load
Sharing to IESG for Proposed Standard

Jun 03  Submit updates to Auto Configuration (RFC2462) and Neighbor
Discovery (RFC2461) to be republished at Draft Standard.
Jun 03  Submit Update to Privacy Extensions for Stateless
Autoconfiguration document (RFC3041) to the IESG for Draft
Standard. 
Aug 03  Submit IPv

Re: Summary Re: Proposal for site-local clean-up

[Bob Hinden]

Brian,

I don't think it is wise to ask the IESG to reconsider the address 
architecture (this is more than an editorial change to the RFC-editor).  I 
also think the issues regarding the usage of site-local are more 
complicated that can be expressed in a paragraph.

I don't think we will get a consensus on this one way or another.  This is 
IMHO about people making different benefit vs. complexity tradeoffs.  Like 
many other things in the IETF that there is disagreement on, I think it is 
better to document what it is and why it isn't a good idea and move on.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Atlanta IETF IPv6 Agenda Planning

[Bob Hinden]

The IPv6 working group has two session at the Atlanta IETF meeting.  They are:

   MONDAY, November 18, 2002, 1930-2200 (Salon III)
   THURSDAY, November 21, 2002, 0900-1130 (Salon III)

There are several topics that we feel are important to devote significant 
meeting time on.  These are:

  - DNS Discovery
  - Flow Label
  - MIB Updates
  - Node Requirements
  - Prefix Delegation
  - Site-Local Usage / Scoped Address Architecture

Please send us requests for agenda items.  We will be giving priority to 
the above topics, but will fit other things in as time allows.  For this we 
will give preference to current working group 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://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

A few comments on Site-Local Useage

[Bob Hinden]

[Working group chair hat off]

A few comments on the Site-Local discussion that I did not see getting 
discussed or proposed.

There was a reference made to networking airplanes somewhere in this 
thread.  If my memory is correct, the airplane industry did select an open 
standard for airlines.  Some planes run ISO CLNP over FDDI.  They did pick 
an open standard, but.

A lot of the discussion seems to imply that site-local addresses are 
created automatically (like link-local).  This is, of course, not the 
case.  Site-local are only created if someone configures a router with a 
specific site-local address on an interface and tell the router to 
advertise the prefix in a routing protocol to other routers and to 
advertise it to hosts on the link in RAs.  Site-local addresses will only 
appear in a site if an administrator decided to configure them.

It seems to me that from a reachability point of view there isn't too much 
difference between using site-local addresses and having a firewall that 
blocks traffic from one set of global addresses and another.  Firewalls 
create limited scope addresses from global addresses.  If one assumes the 
existence of IPv6 firewalls, then these firewalls can also enforce site 
boundaries.  Firewalls are essentially doing this today.  Compared to what 
firewalls already do today, this is trivial.  If the site boundaries are 
going to be defined by firewalls, then it is probably less important that 
we have to define multi-site router behavior.

One of the issues that was discussed regarding the ease or difficulty of 
configure site-local scope filters in routers.   It seems to me that the 
simple way of doing this is configure the router with the zone that each 
interface is in.  The router would then automatically create internal 
filters that enforce the site boundaries.  This seems much easier to me 
than having to create filter rules based on the prefixes that are assigned 
to each interface.

Another router issue that gets talked around is should packets with 
site-local destination be forwarded to "default".  Given that site-local 
addresses are not created without being configured, one approach could be 
to have a "black hole" route for FEC0::/10 preconfigured in all 
routers.  The router would then only forward packets with site-local to 
destinations that matched more specific routes.  They would never get 
forwarded to the ISP via the normal default route.

From a private exchange with someone from a router vendor.  They are 
taking the approach of creating a "no-site" site in their product.  That is 
if an interface configured to be in the "no-site" site, the router will not 
forward any packets with site-local addresses to/from this interface.  This 
might make for a simple default behavior site border router.

Bob



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Scoping Scoped Addresses

[Bob Hinden]

Please excuse the pun in the title, but I wanted to get your attention :-)

[Working group chair hat on]

I have been trying to make some sense of this discussion.  The only obvious 
conclusion is that there is not a consensus in the working group on how 
site-local addresses should be used.

Some people think that site-local is an important feature with many uses, 
others think they are bad and should not be used.  Some think they provide 
security, some do not.  Some thing they help with renumbering, some do 
not.  Some thing they help avoid IPv6 NAT's, some think they encourage IPv6 
NAT's. Etc., etc.  The only thing that is clear is there are a significant 
number of people who have different views on this topic.  It's doubtful 
that one group will convince the other group.  One positive result of the 
discussion was that the issues and benefits are better understood.  The 
real question for the working group is what to do next.

Now that the IPv6 Address Architecture was approved as a Draft Standard and 
the Default Address Selection document was previously approved, we have 
site-local addresses in IPv6 and a set of default rules for how an 
implementation selects them.  What we don't have is how they should be used 
or not-used.

Even though there is no consensus on how site-local addresses should be 
used, I think there is enough people who want to use site-local that it is 
reasonable that the w.g. should continue trying to flesh out site-local 
usage as well as pitfalls of usage.

Here is a proposal for how to proceed from here that tries to take into 
account both sides of the discussion.

1) Node Requirements should not require any multi-site 
implementations.  The only site-local requirement should be limited to what 
is currently in the address selection rules and for routers to configure 
site-locals just like any other unicast prefix.  Vendors are free to go 
beyond this in their products, but the IETF won't require it.

2) People who think the usage of site-local is harmful should write a draft 
titled something like "Use of Site-local Addresses Considered 
Harmful".  The people in the other camp can comment to make sure the 
arguments are accurate.

3) People who want to use site-local addresses should work on completing 
the "IPv6 Scoped Address Architecture" document (and other docs if 
needed).  I think a good focus for this would be to focus on the simplest 
cases.  Topics to cover need to include site border routers, adding 
site-local addresses in the DNS, routing protocols, the use of firewalls to 
enforce site boundaries, and guidelines on how applications might want to 
select between global and site-local addresses.  The people in the other 
camp can review this work and make sure the technical content is accurate.

I believe this approach should help provide the larger community (e.g., 
vendors, ISP's, enterprise operators, etc.) the information they need to 
make an informed decision on the usage of site-locals.

Bob

p.s. I will also send out a few personal comments on site-locals in a 
separate email.


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Comments on IPv6 Flow Label Last Call

[Bob Hinden]

The IPv6 w.g. chairs believe there are some important open issues that they 
would like to see the working group discuss as part of the working group 
last call on the  "IPv6 Flow Label Specification" 
.

The current draft allows flow labels to be used in ways that go beyond the 
consensus that was reached when the working group agreed to make this 
document a working group document.  This consensus was that the flow label 
would be set by a source node to label a set of packets (with same source 
and destination addresses) that the source wanted to be treated as a 
flow.The flow label in this definition did not have any defined 
structure.  The main application for this was to make it easier for other 
nodes to recognize flows without having to search to one or more headers to 
find the transport port numbers.  The current draft has a number of 
features that go beyond this model and permit many other modes.  Examples 
include:

   - Allowing for other standard specifications to define properties and/or
 structure of the flow label field.
   - A strong focus on the assignment of flow label via signaling protocols.
   - Allowing a specific flow label value to be assigned via a signaling
 protocol to identify flows with different source and destination
 addresses.

The draft may be trying to accommodate uses of the flow label that were not 
agreed to by the working group.

There are a number of other areas in the draft that need additional 
discussion and/or clarification.  These include:

  - No default time out for the life time for specific flow label values.
  - No requirement that signaling mechanisms must include a lifetime
when providing flow label setup information.
  - No default mechanisms if flow label values requested via a signaling
mechanisms conflict with existing flow label values.
  - Security considerations need to discuss the impact of labeling flows
of encrypted traffic.

The chairs would like to see these issues discussed by the working group in 
the last call.

Bob Hinden, Steve Deering, Margaret Wasserman




IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "IPv6 Flow Label Specification"

[Bob Hinden]

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

Title   : IPv6 Flow Label Specification
Author(s)   : J. Rajahalme, A. Conta, B. Carpenter, S. Deering
Filename: draft-ietf-ipv6-flow-label-03.txt
Pages   : 7
Date: 2002-9-11

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  The w.g. last call will end on 30 
October, 2002.

Bob Hinden / Steve Deering / Margaret Wasserman


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Bob Hinden]

Brian,

I think this goes to far.  We have recently had a long discussion on the 
list regarding unicast site-local that concluded with keeping the 
definition of unicast site-local addresses in the document (see my email on 
21 Jun 2002, titled "Consensus on Site-Local Discussion").  Part of that 
was that we would add text to the Node Requirements document that nodes are 
only required to implement the rules specified in the default address 
selection document (now a Proposed Standard) and that there be no 
requirement that a node must be able to be part of more than one zone.

Bob

I would go a step further.  Since almost no one has implemented the
routing/forwarding of scoped addresses (multicast & unicast site
locals), I recommend:

 1. Move all discussion of multicast scopes out of the addr-arch
and into the scoped addr-arch doc
 2. Move all text on site-local unicasts out of the addr-arch
doc and into the scoped addr-arch doc
 3. Add explicit text to the scoped addr-arch doc to define
how/when/where these scopes should be used

This would allow the addr-arch doc to progress to DS without being
hung up on text involving scoped addresses but still describing the
pieces that we know work (e.g. global and link-local).  It would also
make a clean delineation between global and scoped addresses.

The scoped addr-arch doc can then be the home for future work on
scoped addresses.

My reasoning is based on actually having implemented scoped routing
and forwarding.  It is not trivial or for the weak of heart.



IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt

[Bob Hinden]

At 10:01 AM 10/11/2002, Margaret Wasserman wrote:


At 02:25 PM 10/10/02, Robert Elz wrote:

So would I.   The change I would make is to delete all references
of subnet-local from the addr-arch doc, and simply leave those values
as "to be defined" and then define them in the scoping-arch doc.


This seems reasonable to me.


To clarify this, I think the proposal is to change the definition of the 
multicast scope value 3 from "subnet-local scope" to "unassigned".  The 
table in section 2.7 Multicast Addresses would be changed to:

scop is a 4-bit multicast scope value used to limit the scope of
the multicast group.  The values are:

 0  reserved
 1  interface-local scope
 2  link-local scope
 3  (unassigned)
 4  admin-local scope
 5  site-local scope
 6  (unassigned)
 7  (unassigned)
 8  organization-local scope
 9  (unassigned)
 A  (unassigned)
 B  (unassigned)
 C  (unassigned)
 D  (unassigned)
 E  global scope
 F  reserved

Also, the definition of subnet-local multicast scope that follows would be 
removed.

If there is agreement to make this change, I could issue a new draft next 
week.  This should resolve the issue that Rob Austen raised.

Bob


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

IPv6 w.g. Last Call on "Well known site local unicast addresses for DNS resolver"

[Bob Hinden]

This is a IPv6 working group last call for comments on advancing the 
following document as a Proposed Standard:

	Title		: Well known site local unicast addresses for DNS
 resolver
	Author(s)	: A. Durand, J. Hagino, D. Thaler
	Filename	: draft-ietf-ipv6-dns-discovery-06.txt
	Pages		: 12
	Date		: 2002-9-19

Please send substantive comments to the ipng mailing list, and minor 
editorial comments to the authors.  This last call period will on 25 
October, 2002.

Bob Hinden / Steve Deering / Margaret Wasserman


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IPv6 protocol usage

[Bob Hinden]

Guru,

There is an implementation page at

   http://playground.sun.com/ipv6

It not completely up to date, but should get you started.

Bob

At 07:33 AM 9/19/2002, Guru yeleswarapu wrote:


>Hi,
>We are a chip company and looking at embedding ipv6 into our chip.
>We are looking at the need of doing that by exploring who implemented
>in what areas, how much is in use etc.,?
>
>I appreciate if some one can throw light on what companies have already
>implemented and how much efficinet it is from IPv4 and and related pointers
>
>
>Thanks in advance
>Gurumurthy Yeleswarapu
>
>
>IETF IPng Working Group Mailing List
>IPng Home Page:  http://playground.sun.com/ipng
>FTP archive:  ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [EMAIL PROTECTED]
>


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Re: IESG comments on draft-ietf-ipngwg-addr-arch-v3-09.txt

[Bob Hinden]

To resolve this issue, I propose the following text for section 2.2 
(changed line indicated by "|" ):

  2. Due to some methods of allocating certain styles of IPv6
 addresses, it will be common for addresses to contain long strings
 of zero bits.  In order to make writing addresses containing zero
 bits easier a special syntax is available to compress the zeros.
 The use of "::" indicates one or more groups of 16 bits of zeros. |
 The "::" can only appear once in an address.  The "::" can also be
 used to compress the leading and/or trailing zeros in an address.

Unless there is an objection, I will submit a new draft tomorrow with this 
change (as well as the reference and obsoletes RFC2373 changes).

Bob

At 09:36 AM 9/12/2002, Thomas Narten wrote:
>Good news. The IESG discussion of this document raised no major
>issues. One point that was discussed, however, was related to whether
>:: means "1 or more" occurances of zero vs. "2 or more", when used in
>an IPv6 literal address. The document currently says:
>
> >2. Due to some methods of allocating certain styles of IPv6
> >   addresses, it will be common for addresses to contain long strings
> >   of zero bits.  In order to make writing addresses containing zero
> >   bits easier a special syntax is available to compress the zeros.
> >   The use of "::" indicates multiple groups of 16 bits of zeros.
> >   The "::" can only appear once in an address.  The "::" can also be
> >   used to compress the leading and/or trailing zeros in an address.
>
>It turns out that an unscientific survey (one AD who got bitten once
>and recalled not understanding what was wrong with the address being
>typed in and another that then checked their implementation) at least
>two implementation happen to implement this differently. I.e., on one
>parser an address with :: denoting one occurance of zeros was
>accepted, on the other it was rejected.
>
>It would be good for the WG to clarify what meaning should be
>implemented, and then clarify the document. Once that is  done, I
>expect the IESG to approve the document.
>
>Some other nits to fold in:
>
> > Minor nit. The first reference to EUI-64 should contain a reference.
>
> >   this document does not say anywhere that it obsoletes
> >   RFC 2373 - nor does the protocol action
>
>Thomas


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

Consensus on IPv6 Addressing Architecture

[Bob Hinden]

The IPv6 working group chairs belive there is a consensus to adopt the 
changes proposed to the mailing list on 09 August 2002 and to advance the 
document to Draft Standard.  The discussion on the mailing was subsequent 
to a discussion at the Yokohama IETF.

The changes were to modify the interface identifier uniqueness requirements 
(from link to subnet prefix) and to change the definition of Site-Local 
addresses to make the subnet field 54-bits (and eliminate the 38-bit zero 
field).  There was no disagreement to the subnet field change.

There was a discussion about the interface identifier uniqueness 
change.  One issue raised was about the operational complexity of having 
different nodes using the same interface identifier (in different 
subnet-prefixes).

The following text (changed lines marked by "|") resolves this issue:

   2.5.1 Interface Identifiers

   Interface identifiers in IPv6 unicast addresses are used to identify
   interfaces on a link.  They are required to be unique within a subnet |
   prefix.  It is recommended that the same interface identifier not be  |
   assigned to different nodes on a link.  They may also be unique over  |
   a broader scope.  In some cases an interface's identifier will be
   derived directly from that interface's link-layer address.  The same
   interface identifier may be used on multiple interfaces on a single
   node, as long as they are attached to different subnets.  |

The recommendation in the third sentence should accommodate the desired 
behavior while still relaxing the uniqueness requirement.

Subsequent to discussion on the proposed changes, questions were raised 
about the necessity of 64-bit interface identifiers and the /64 boundary in 
IPv6 unicast addresses.  The chairs reading of the discussion is that we do 
not believe there is a consensus to make changes in this part of the IPv6 
addressing architecture and the document can proceed.

A new version of the draft (-09) has been submitted to be published as an 
Internet Draft.  A few minor changes to the document were made in Appendix 
A to make the text consistent with the interface identifier uniqueness change.

The IPv6 working group chairs believe there is a consensus to advance this 
document to Draft Standard and plan to notify the Internet ADs accordingly.
    
Bob Hinden, Steve Deering, Margaret Wasserman
IPv6 Working Group Chairs


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]

RE: Changes to IPv6 Addressing Architecture Draft

[Bob Hinden]

Julian,

Thanks for catching this.  I will fix this before publishing a new ID.

Bob

At 02:31 PM 8/12/2002, Sellers, Julian P wrote:
>Bob Hinden wrote:
> >
> > Change to second sentence in the first paragraph of section 2.5.1:
> >
> >   Interface identifiers in IPv6 unicast addresses are used to identify
> >   interfaces on a link.  They are required to be unique within a subnet  |
> >   prefix.  They may also be unique over a broader scope.  In some cases  |
> >   an interface's identifier will be derived directly from that
> >   interface's link-layer address.  The same interface identifier may be
> >   used on multiple interfaces on a single node, as long as they are
> >   attached to different links.
>
>The last sentence of the paragraph is no longer correct.  The addresses
>::1 and ::1 can be on the same link and even on the same
>interface.  In addition, I see no need for the two sentences that precede
>that sentence or for the paragraph that follows it.
>
>Appendix A needs changes also.  Under the heading "Links without
>Identifiers", I find five references to link-unique interface IDs instead of
>subnet-prefix-unique interface IDs.
>
>Julian
>
>IETF IPng Working Group Mailing List
>IPng Home Page:  http://playground.sun.com/ipng
>FTP archive:  ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to [EMAIL PROTECTED]
>


IETF IPng Working Group Mailing List
IPng Home Page:  http://playground.sun.com/ipng
FTP archive:  ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]