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
. 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
: 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
-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
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
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
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
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,
Jim,
At 07:18 AM 8/9/2003, Bound, Jim wrote:
We now have a combined local addressing requirements document
draft-hain-templin-ipv6-limitedrange-00.txt, a specific
alternative to
site-local addresses draft
draft-hinden-ipv6-global-local-addr-02.txt
(accepted as a working group item at the
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
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
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
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
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
list, and minor
editorial comments to the authors. This last call period will end on 16
July 2003.
Bob Hinden / Margaret Wasserman
IETF IPng Working Group Mailing List
IPng Home Page: http
-ietf-ipv6-rfc2011-update-03.txt
Pages : 114
Date: 2003-7-2
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the author. This last call period will end on 16
July 2003.
Bob Hinden / Margaret Wasserman
: draft-ietf-ipv6-rfc2012-update-03.txt
Pages : 25
Date: 2003-6-26
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end on 16
July 2003.
Bob Hinden / Margaret Wasserman
Date: 2003-6-30
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end on 15
July 2003.
Bob Hinden / Margaret Wasserman
IETF
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
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
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
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
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
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
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
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
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
[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
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
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*
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
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
Attached is a copy of the charter we sent to the Internet ADs.
Bob Hinden Margaret Wasserman
Internet Protocol Version 6 (IPv6) Working Group Charter -- DRAFT
Chairs:
Bob Hinden [EMAIL PROTECTED]
Margaret Wasserman [EMAIL PROTECTED]
Description of the Working Group:
The IPv6 working group
working
group last call is desirable to verify the consensus before forwarding the
document to the IESG.
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors. This last call period will end on 11
March 2003.
Bob Hinden / Margaret Wasserman
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
documents and last to status
reports.
Thanks,
Bob Hinden and Margaret Wasserman
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
Thomas, Erik,
The chairs belive that based on the email on the mailing list there is a
consensus in the IPv6 working group to publish the IPv6 Addressing
Architecture (draft-ietf-ipngwg-addr-arch-v3-11.txt) as a Proposed Standard
as recommended below.
Bob Hinden and Margaret Wasserman
IPv6
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
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
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
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
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
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
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
Patrick Grossetete just pointed out to me that there is already a prefix
allocated (by APNIC) for documentation. It is:
2001:0DB8::/32
For more details see:
http://www.apnic.org/info/faq/ipv6-documentation-prefix-faq.html#3
Since I don't think we need two, I will remove the one I proposed
Pekka,
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
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
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
-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
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
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
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
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.
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
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
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
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
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
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
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:
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:
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
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
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
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
[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.
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
-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
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
.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
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
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
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
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
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
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
At the IPv6 working group sessions at the Yokohama IETF two changes to the
IP Version 6 Addressing Architecture draft
draft-ietf-ipngwg-addr-arch-v3-08.txt
were discussed. These changes were proposed based on feedback received
from our area director and email discussion on the mailing
we might have the following choices (I can't think of other combinations that
make sense to me):
1. all are optional
2. load sharing is mandatory; others are optional
3. load sharing and router preferences are mandatory; more specific is
optional
4. all are mandatory
The current proposal is
Rich,
draft-ietf-ipv6-host-load-sharing-00.txt with router-selection.
If I understand the intent, I believe it is a mistake to merge the two
documents. It would be better to keep all mandatory changes to the ND
spec in a way that they are clearly identifiable. Burying mandatory
Rich,
My recommendation is to publish them separately. This will
require some
small changes in the default router selection document
(keeping the load
sharing, but changing the mandatory/optional text).
I don't quite understand. Are you saying keep the load-sharing section
in the
,
thermometers, network appliances, etc. I think it should be a fun
presentation.
It will be held in the lunch break between the two IPv6 working group sessions:
Thursday, July 18th, 1145-12:45 (Room 301/302)
Suggest that you may be able to arrange a box lunch through your hotel.
Bob Hinden
I will try to get the slides and put them on playground.sun.com after the
session.
Bob
At 09:04 PM 7/16/2002, jaganbabu rajamanickam wrote:
Hi Bob,
If you send the IPV6 App presention link (if any)
which you have mensioned below then it would be great.
Thanx
Jags
Rob,
I think something with similar properties to TCP's initial sequence number
selection would be about right. A toaster-class device will have to deal
with that as well.
Bob
Please also recall that there exist toaster-class devices whose only
persistant storage is flash RAM or some
. Draves, B. Hinden
Filename:draft-ietf-ipv6-router-selection-02.txt
Pages: 13
Date:10-Jun-02
A working group last call for this document was completed on July 4, 2002.
Bob Hinden / Steve Deering / Margaret Wasserman
IPv6 Working Group Co-Chairs
to honor all requests for agenda items. Suggest that these topics
be brought to the mailing list.
Please send comments and corrections to the w.g. chairs.
Thanks,
Bob Hinden, Steve Deering, Margaret Wasserman
IPv6 chairs
).
- The working group should complete the Scoped Address Architecture draft.
Bob Hinden, Steve Deering, Margaret Wasserman
IPv6 working group chairs
IETF IPng Working Group Mailing List
IPng Home Page: http
Keith,
At 09:29 AM 6/21/2002, Keith Moore wrote:
I agree that there's probably not consensus to deprecate SL,
but I think we should consider finding ways to discourage its use,
and to remove the burden from apps of having to support it specially.
I don't agree that the Default Address Selection
-ietf-ipv6-cellular-host-03.txt
Pages: 20
Date: 07-Jun-02
A working group last call for this document was completed on May 27,
2002. This draft resolves issues raised during the working group last call
and subsequent discussion on the mailing list.
Bob Hinden / Steve
comments to the list.
Thanks,
Bob Hinden, Steve Deering, Margaret Wasserman
IPv6 w.g. Co-Chairs
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive
period will on May 30, 2002.
Bob Hinden / Steve Deering / Margaret Wasserman
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp
Rob,
Two points not made previously.
thread. Using well-known unicast addresses still moves knowledge of
the server location into the routing system. Using well-known anycast
addresses still leaves the client unable to take any useful recovery
action if the server location mechanism has
Rob,
Apologies in advance if this sounds grumpy, it's not intended that
way, I just haven't had enough coffee yet today. :)
Coffee is a good thing!
To clarify draft-ietf-ipv6-dns-discovery-04.txt
Sections 1 through 8 is the main body of the proposal (called level 1) and
is what is being
Rob,
I think you mentioned in an earlier email about the need for NTP in order
to use DNSSEC.
From the discussion on the list it sounds like the timing requirement for
DNSSEC is for the host to have a clock that is +/- 5 minutes. This could
be implemented with NTP or something else (e.g.,
Thomas,
At 07:18 AM 4/29/2002, Thomas Narten wrote:
There are issues raised in solutions like this to insure that the
co-located services are adequately tied together. For example in case
of a
DHCP server in the DNS server the processes need to be tied together
in a
manner that the
Rob,
Sorry for not responding sooner.
The emphasis in the definition is with out any dependence on resources
other than are needed. This would allow relay agents in routers or DHCP
servers in DNS servers.
There are issues raised in solutions like this to insure that the
co-located services
Ralph,
At 05:28 AM 4/23/2002, Ralph Droms wrote:
Here's my cut at a list of requirements for DNS Configuration. It's based
on Bob's IPv6 DNS Discovery Requirements Statement, previous discussions
on DNS configuration, and my own $0.02. My intention is to list all of
the requirements I've
Rob,
Thanks. I will give it some thought and respond tomorrow. I will not have
email for most of today.
Bob
At 09:12 PM 4/22/2002, Rob Austein wrote:
At Mon, 22 Apr 2002 13:57:02 -0700, Bob Hinden wrote:
Could you comment on the definition I used for server-less? There
was more than
Could you comment on the definition I used for server-less? There was more
than just the use of the word.
Bob
At 10:30 AM 4/19/2002, Rob Austein wrote:
At Fri, 19 Apr 2002 09:50:01 -0700, Bob Hinden wrote:
I suspect that most people can tell the difference.
No, Bob, that's exactly
Thomas,
I think this point is important because saying we need a server-less
solution implies we all agree on what server-oriented vs. server-less
actually means. I'm not sure I do.
I suspect that most people can tell the difference. I used these words I
thought were clearer than
I took a cut at a requirements statement for IPv6 DNS Discovery. Comments
are appreciated.
Thanks,
Bob
--
IPv6 DNS Discovery Requirements Statement
IPv6 provides two approaches to basic IPv6 configuration. One is
server-less and is defined in IPv6 Neighbor Discover
1 - 100 of 181 matches
Mail list logo
