All,
I have just submitted an update to the IP Forwarding MIB
that addresses all the last call comments. If you cannot wait
for the I-D editor announcement, a copy is availale at
http://www.innovationslab.net/~brian/drafts/fwdmib.txt.
Regards,
Brian
Hi Geoff,
Geoff Huston wrote:
I see that the local use address draft has been revised and published
as a WG
document.
In section 3.2.2 of the draft, it notes that, in reference to Locally
Assigned Global IDs that the likelihood of conflict is small.
I had noted in
There have been several comments on eliminating the
user input portion of the random selection algorithm.
This would, primarily, provide the capability to
automate the prefix generation process. After assessing
issues with this, I have two possible proposals:
1. Re-use the random ID process
Mike,
Thanks for the comments. I have a few follow-ups in-line...
1.) The rationale for adding inetCidrRouteDiscards (and deprecating
ipRoutingDiscards in 2011-update) is not documented. While I don't
entirely agree with that decision, I can accept it based on the
following explanation
Bob Hinden wrote:
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
Thomas Narten wrote:
Hi James.
However, I believe some of the resistance to deprecation may be the
result of people who have implementations and would rather not have
to pay the costs of ripping out that code and putting in something
new.
This I don't understand. AFAIK, there is little or no
Erik Nordmark wrote:
Each zone is required to be convex from a routing
perspective, i.e., packets sent from one interface to any
other interface in the same zone are never routed outside
the zone.
No one has objected to it. I have implemented the routing of
scoped addresses.
Erik Nordmark wrote:
Correct. My statement was for the protocol, not the forwarding.
That is why I made the follow-on comment about complexity. The
next-hop interface's ifindex for the global destination address
would have to be checked to ensure that it has the same zone ID
as the interface on
Erik,
Erik Nordmark wrote:
If we have statefull address autoconfig stateful address autoconfig, I
think having an additional mechanism for getting DNS server addresses is not
a bad thing. At the transport layer, we have UDP, UDP-lite, DCCP, TCP,
SCTP ... to transfer packets. Having multiple
Pekka Savola wrote:
On Sat, 8 Mar 2003, Tim Chown wrote:
On Sat, Mar 08, 2003 at 06:45:15PM +0200, Pekka Savola wrote:
No comments from the w.g. except by me and the author.
RA-piggybacking has a few different nuances, and I'm not sure if I think
the one proposed is necessarily the best one,
MLD-snooping switches is the biggest reason.
Brian
Siva Veerepalli wrote:
RFC2710 (MLD) states that when a General Membership Query is received, a
node listening to the query sends a membership report for all multicast
addresses it is listening to, excluding the all-nodes link-local
multicast
Siva Veerepalli wrote:
At 02:32 PM 2/27/2003 -0500, Brian Haberman wrote:
MLD-snooping switches is the biggest reason.
Ok. So, it seems like there would be no need to send these reports for
link-local multicast on point-to-point links. Should this clarification
be made in the IPv6 over PPP
Markku Savela wrote:
RFC 2462 says that the node MUST join the solicited-node
multicast group (which implies using MLD) when performing
DAD.
Presumably it needs to do the MLD join with ::-src address, because
before DAD address is not yet valid.
That is exactly what
I agree that Informational is the correct level. I also
don't see anything in the doc that is new and needs to
be a Standard.
Regards,
Brian
Thomas Narten wrote:
Yes. Obsoleting 2374 is (from what I can tell) the point of this
document. IMO, putting more into the document than needed to
Brian E Carpenter wrote:
Brian Haberman wrote:
[EMAIL PROTECTED] wrote:
Hi Ralph,
The text looks really good, what do other thinks? Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?
I tend to agree with the SHOULD. Since these nodes recognize
Jari Arkko wrote:
[EMAIL PROTECTED] wrote:
Hi Brian(s);
My concern is the scenario where an operator knowingly disables
prefix advertisements and enables DHCPv6. If the nodes doesn't
do DHCP, it is stuck with only the link-local address.
Understood. That certainly deserves a health
[EMAIL PROTECTED] wrote:
Hi Ralph,
The text looks really good, what do other thinks? Does anyone
have a preference for Stateful Address Autoconfiguration to be
a SHOULD or a MAY?
I tend to agree with the SHOULD. Since these nodes recognize the
'M' 'O' bit-settings, they should be capable of
Mika Liljeberg wrote:
Hi Brian,
On Wed, 2003-01-29 at 00:03, Brian Haberman wrote:
The RR mechanism for anycast already requires the ability to use
the anycast address as a source address. If we can get agreement
on lifting that restriction, I like the idea of keeping changes
out of TCP
Mika Liljeberg wrote:
On Wed, 2003-01-29 at 13:23, Brian Haberman wrote:
Mika Liljeberg wrote:
I just spotted the following: the RR mechanism sends HoT to the anycast
address. How does that work? It might go to a completely different
server.
There is an assumption that there won't
Susceptibility to DoS attacks is another consideration that needs some
attention, I think. The RR mechanim in MIPv6 is designed to require no
state in CN, but in the anycast RR mechanisms the roles are reversed:
here the anycast server is the one holding state.
Is that really true? What about
I happened to read through a few older anycast-related drafts; a few
comments, to try to spark some discussion on how to go forward with
anycast. Last, I bring up one idea how to possibly make TCP+anycast work,
in relatively simple terms.
1) draft-haberman-ipngwg-host-anycast-01.txt
Pekka Savola wrote:
On Mon, 27 Jan 2003, Brian Haberman wrote:
There are a _lot_ of issues there, especially if one anycast address can
have joins from across multiple routers. Even more so if from across
multiple sites/AS's, or more specifically (with some terminology pixie
dust) an IGP/iBGP
[EMAIL PROTECTED] wrote:
Yes that is what the spec says, but reality is always somewhat
different. There is no technical reason that an anycast address could
not be assigned to any group of hosts. The issue that must be dealt with
there are technical reasons why anycast addresses can only be
Fred L. Templin wrote:
Brian Haberman wrote:
Each ipv6-over-foo doc discusses modifications to ND,
if necessary, for the particular link technology.
Can you point me to any text in the core architecture
documents (e.g., RFCs 2461, 2462) that allow this and
can be used as normative reference
Ole Troan wrote:
Each ipv6-over-foo doc discusses modifications to ND,
if necessary, for the particular link technology. For
example, Section 5 of RFC 2023 (IPv6 over PPP) mentions
that DAD is redundant and needn't be run.
my interpretation of IPv6 over PPP is different. DAD is redundant only
Margaret Wasserman wrote:
Current text:
Hi Brian,
Site-local addresses are designed to be used for addressing
inside of
a site without the need for a global prefix. Although a subnet ID
may be up to 54-bits long, it is expected that globally-connected
sites will use the
BELOEIL Luc FTRD/DMI/CAE wrote:
Does anyone think that a validity lifetime should be associated to the
prefix during prefix delegation?
Absolutely.
Indeed RAs sent on a link associate a valid lifetime and a preferred
lifetime to the advertised prefixes.
If your prefix is delegated to you,
Pekka Savola wrote:
On Thu, 7 Nov 2002, Keith Moore wrote:
What I meant to say that to implement site-locals properly in a router,
the vendor should not be OK to say we support access-lists, you can use
them to configure site-local borders or that we have nice firewall
products, wanna buy one?.
Ole Troan wrote:
[...]
The biggest hit is actually in the forwarding. Each packet
gets at least one additional table lookup (for the incoming
zone id). Then there are the checks to ensure that the source
address is valid (e.g. a site-local SA and global DA trying
to cross a site border).
Mark Smith wrote:
On Thu, 2002-10-31 at 13:13, Brian Haberman wrote:
Tony Hain wrote:
Mark Smith wrote:
...
On a related topic, if I was to stuff up my site local
filters at the edge of my site, would my network then become
part of my ISPs site local network ?
You would both have
Margaret Wasserman wrote:
I don't see a performance drop in our implementation. an additional
table lookup is not needed for forwarding. you need to figure out the
scope of the DA of course, but that is needed for link-local/multicast
anyway.
The issue is that you also have to check the
So, one of the items that Margaret suggested was some text in
the node requirements doc or the scoped addr arch that states
that nodes default to being in one site.
However, there has been some mention that people would prefer
different behavior in routers. That is, the stated desire
was that,
For the record, my opinion follows Ole's comments.
Brian
Rob Austein wrote:
What Ole said.
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive:
Of Brian Haberman
Sent: Wednesday, October 30, 2002 10:46 AM
To: [EMAIL PROTECTED]
Subject: Default site-local behavior for routers
So, one of the items that Margaret suggested was some text in
the node requirements doc or the scoped addr arch that states
that nodes default to being in one site
Jun-ichiro itojun Hagino wrote:
could you comment on routing code? (RIPng, OSPFv3) i still think
it's way too tough to support multi-sited node.
Not that the chairs have finalized the agenda, but I am planning
on presenting what it took me to get a site-border router coded
and running.
Tony Hain wrote:
Mark Smith wrote:
...
On a related topic, if I was to stuff up my site local
filters at the edge of my site, would my network then become
part of my ISPs site local network ?
You would both have to make an error to get the two IGPs tied together.
In the proposed
Mark,
[EMAIL PROTECTED] wrote:
Pekka Savola wrote:
On Tue, 29 Oct 2002, Brian Haberman wrote:
Note that KAME only supports this through manual configuration (and a
fix) -- clarified in off-the-list discussion.
To be compliant with the paragraph:
Routers must not forward any packets
Rich,
Richard Draves wrote:
Some read it (many):
if I configure a site here, I must also block site-locals
from spreading
out or false site-locals coming in
Some others read it:
if I use site-locals here, my upstream router will block
the site-local
addresses from spreading out and
Margaret,
Margaret Wasserman wrote:
At 12:17 PM 10/24/02, Margaret Wasserman wrote:
I think that we should keep site-local addresses in the
addressing architecture, but limit their use to non-globally-
connected IPv6 networks.
Some folks have pointed out that it might have been helpful if
I
Hi Roy,
Roy Brabson wrote:
This is craziness. We (I don't mean just MS) have shipping
implementations that support site-locals. We have operational
deployments using site-locals. We have applications that work just fine
with site-locals.
Could you (or someone else who has this working)
Rich,
Just for my edification:
1. Who else has site-local support?
2. Can you describe the operational deployments?
3. What applications?
Thanks,
Brian
Richard Draves wrote:
This is craziness. We (I don't mean just MS) have shipping
implementations that support
Hi John,
[EMAIL PROTECTED] wrote:
Hi all,
The nodes requirement draft has a number of issus to be addressed, so I would
like to send a list of open issues then send possible resolutions to the
issues in seperate mails.
1) What is the correct level of support for MLD? Should MLDv2 be
Keith,
Keith Moore wrote:
My point is that I believe that a clean separation should be made
between global addresses and scoped addresses. We fully understand
how globals and link-locals work. All the others are still being
hashed out. If we make this break, the address architecture can
Bob,
I went back and re-read the thread you mention below. There is
absolutely no reason why discussion of site-locals couldn't be moved
to the scoped addressing architecture doc. It wouldn't affect the
text needed in the Node Requirements draft and it would put all the
scoped addressing
Rob Austein wrote:
At Fri, 11 Oct 2002 14:13:45 -0700, Bob Hinden wrote:
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
I have written about this
Dave Thaler wrote:
-Original Message-
From: Brian Haberman [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 09, 2002 1:48 PM
To: [EMAIL PROTECTED]
Subject: Re: IPv6 subnet-local addresses and
draft-ietf-ipngwg-addr-arch-
v3-10.txt
Dave Thaler wrote:
From: Brian
Pekka Savola wrote:
On Wed, 9 Oct 2002, Erik Nordmark wrote:
[snip]
I'm not worried about this. We have exactly the same issue for routing table
lookup in hosts and routers; there is no specification that states how
to implement caching schemes.
We haven't really specified the source
Dave Thaler wrote:
From: Brian Haberman [mailto:[EMAIL PROTECTED]]
The more I think about it, the more I realize that automagically
creating the subnet-local scope zone id isn't going to work.
Especially with multiple prefixes per interface.
Why not? Can you elaborate?
Shouldn't it always
Robert Elz wrote:
Date:Sun, 06 Oct 2002 10:38:32 -0400
From:Margaret Wasserman [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| You haven't provided the information that router B would use
| to make that determination.
Brian Haberman provided
Margaret Wasserman wrote:
I'm not sure, though, that Brian's explanation is consistent with the
following line in the scoped address architecture:
Each interface belongs to exactly one zone of each possible scope.
Based on Brian's explanation, it would seem like the interfaces of
It is possible that we could do a combined version of these
two choices:
- The IPv6 WG does the minimal updates to make the
current IPv4 MIBs version-independent.
- State-of-the-art MIBs are developed in other areas
and groups, as appropriate.
What do you folks
Robert Elz wrote:
The only thing to be aware of, is that we (IPv6) must avoid getting upset
if we do lots of work to update some particular MIB, and then just before
we're finished, a new better version emerges from elsewhere (which is
intended to deprecate some current v4 only MIB). If
| Every router (whether IPv4 or IPv6) knows what subnets its own interfaces
| belong to (or, more accurately, what subnet numbers are assigned to
| the links to which it has interfaces). That is the most basic
| configuration info provided to a router -- it is provided with that
Mukesh Gupta wrote:
Hi,
Is it required to have a link local address on a tunnel interface. I am
implementing IPv6 in IPv6 tunnels and wanted to know whether I should
install a link local address on the tunnel interface. Is there any
document that talks about this ?
RFC 2373, Section 2.8
Rob,
The subnet-scope is delineated in the same manner as the scopes
6,7,8,9... That is, a router maintains a scope zone id per interface.
So, if I have a router that has interfaces 1,2,3, 4 and the admin
assigns a subnet-local scope zone id of 100 to interfaces 2 and 4,
then 2 and 4 are
Rob Austein wrote:
At Wed, 02 Oct 2002 17:35:37 -0400, Brian Haberman wrote:
The subnet-scope is delineated in the same manner as the scopes
6,7,8,9... That is, a router maintains a scope zone id per interface.
So, if I have a router that has interfaces 1,2,3, 4 and the admin
All,
This starts the MAGMA Working Group 2 week Last Call
period for draft-ietf-magma-mld-source-01.txt. The Last Call
will end on October 3rd. Substantive comments should be
directed to the MAGMA mailing list. Editorial comments can
be made to the author.
Regards,
Brian Bill
All,
Several people have mentioned the conflict that exists between
the MLD spec (RFC 2710) and NDP (RFC 2461). NDP requires nodes to
join the solicited-node multicast address in order to perform Address
auto-config. However, MLD requires the source IPv6 address to be a
valid link-local
Margaret Wasserman wrote:
If
you want to talk DiffServ, IntServ, or something of that flavor, the
flow label would be signaled, the router would recognize it during
packet classification and deal with it how it sees fit.
So, all of the routers would have to participate in signalling to
All,
This is the start of a MAGMA working group last call on the
Multicast Listener Discovery - Version 2 specification.
http://www.ietf.org/internet-drafts/draft-vida-mld-v2-03.txt
The last call period will end on August 13th. Substantive comments
should be directed to MAGMA mailing
Hi John,
[EMAIL PROTECTED] wrote:
I don't disagree with you - however my point was I thought that the
application should be involved in what value of the flow label is used.
Is it really the case that the application needs to be involved in
choosing the flow label value? Or is it more
[EMAIL PROTECTED] wrote:
I don't disagree with you - however my point was I thought that the
application should be involved in what value of the flow label is used.
Is it really the case that the application needs to be involved in
choosing the flow label value? Or is it more
Francis,
I agree that prefix delegation is important for the home sites.
Unfortunately, I will not be at IETF 54 to discuss my prefix delegation
work. If it becomes an agenda item, I will see about getting someone
to participate for me.
Regards,
Brian
Francis Dupont wrote:
In your
Keith,
Keith Moore wrote:
if you have enough bits for the site-id you can make the probability
of a conflict approach zero *provided* the site bits are randomly
chosen. but the easiest way to avoid conflicts is to make the
site-id globally unique, and there's no good reason to not do so.
Keith Moore wrote:
Who delegates the globally-unique site-ids?
presumably ICANN or their designees.
This introduces a management headache. The address registries already
are struggling with managing the global address space. Adding another
registry will not be beneficial.
If the
Keith Moore wrote:
I think there are lots of reasons not to make these site-ids globally
unique, if we choose to adopt them.
name one.
The cost of administration of the global database.
there doesn't need to be a global database. try again.
If there isn't a global
Tony,
Tony Hain wrote:
Keith Moore wrote:
...
of course it's a global address. but that doesn't mean it's globally
routable.
You have just argued yourself into a corner. If the address the app
chooses is not globally routable, how does it connect? Why would it have
chosen SL over
Oops. My mistake.
Brian
Michel Py wrote:
Brian,
And if you want to use AS numbers, just remember that a 64 bit
AS number will not fit inside 37 bits.
I don't think this is a good argument. Today, the AS number is 16 bits.
Tomorrow, it will be 32, which is 4 Billion AS numbers. 37
Keith,
Keith Moore wrote:
in other words, I think we need to seriously question some of the assumptions
behind the scoped addressing architecture, and I'm not confident that
completing the work on the Scoped Address Architecture document will
accomplish that.
Can you enumerate what
Place this in context: what we are talking about here is either a
router-to-router tunnel or a router-to-router link. Guess what: there is
likely to be a routing protocol there. Could you explain me how you
configure RIP when the other router is not on the same subnet?
In all of my labs
:
Brian
Wouldn't the Zone ID for a given site on all routers in that same site
have to be same for this to work?
-vlad
Brian Haberman wrote:
Hi Margaret,
I suppose that I should admit to being remiss in this area. I
have done a fair amount of work in this area and just haven't had
Hi Margaret,
I suppose that I should admit to being remiss in this area. I
have done a fair amount of work in this area and just haven't had the
time to document routing protocol behavior changes to support site
local prefixes (even though I recall telling you I was going to do it).
Ralph,
Ralph Droms wrote:
And, I don't think there's a good way to define default behavior
or auto-discovery for site-local addressing...
Well, we could very easily apply RFC 2776 to the problem. It is
already designed to advertise multicast zones. I may not help
with auto-configuring the
Steve,
Steven M. Bellovin wrote:
Yah. Let's pick a prefix, and tell folks to pick a random number (more
precisely, use an RFC 1750-compatible RNG) to fill out the rest of the
high-order bits to a /48 or a /64. We encourage ISPs to provide real
prefixes to companies that are using
Hesham,
The text looks fine to me.
Regards,
Brian
Hesham Soliman (ERA) wrote:
Hi all,
After some discussion on the list, I'd like to
propose the following text for MLD in the cellular
host draft:
2.9 RFC2710 - Multicast Listener Discovery (MLD) for IPv6
MLD
Kristine,
We will probably have a slot in one of the IPv6 WG sessions to
discuss the mib work. It may also be presented at the ops area
meeting (if held). At least, that is what we have done in the past.
Regards,
Brian
[EMAIL PROTECTED] wrote:
Thanks to everyone who responded
Hesham,
Hesham Soliman (ERA) wrote:
Itojun,
= I've never seen that in any spec.
I guess you are saying that it's needed for L2
switches that snoop MLD messages to decide
on mcast forwarding of mcast ethernet frames?
If so, then we don't have this situation in
Hesham,
Hesham Soliman (ERA) wrote:
incoming packet to ff02::blah
|
H2R--- H1
If only H2 joined, doyou assume that the router will
send it to H1 as well? Why?
Note H1 and H2 do not share the same link.
Maybe I
Let me clarify my comment. ff02::blah is a bad example for what I
am asking. Will the 3G network support applications utilizing mcast?
Will a host be able to join ff05::abcd and receive data on that group
address? If that is supported, then MLD is needed.
Brian
Brian Haberman wrote
Pekka,
Pekka Savola wrote:
Hello,
A few comments.
As stated before by others, this seems like a hack. But sometimes hacks
can be good. Anyway..
The original concept was based on the premise that group membership is
similar in multicast and anycast. The hosts that are a member of a
Erik,
Erik Nordmark wrote:
Brian,
1. Host-to-router notification protocol (this is taken care of by
changes to mld proposed in draft-haberman-ipngwg-host-anycast)
2. Security: at a minimum some form of authentication to allow
routers to determine if hosts
[EMAIL PROTECTED] wrote:
- node with anycast address(*) participating routing exchange
pros: deployable now, routing protocol has mechanisms for
protecting against malicious route injection (sometimes
they are just use IPsec...)
cons: some
[EMAIL PROTECTED] wrote:
Actually, I will have to let on to a little secret. I have been
looking at an option for anycast that looks strikingly similar to the
Home Address option in MIPv6. The idea is that a server responding to
an anycast query will put the anycast address in this
[EMAIL PROTECTED] wrote:
- node with anycast address(*) participating routing exchange
pros: deployable now, routing protocol has mechanisms for
protecting against malicious route injection (sometimes
they are just use IPsec...)
cons:
Generally, hosts already support MLD/IGMP in order to join multicast
groups, so why require them to run a routing protocol?
at this moment no client implementation issues MLD join for
anycast address, so it is a large change to make.
Sure, that is to be expected. The
My concern with the first option is that it requires new functionality
on the host joining an anycast group, namely running a routing protocol.
Generally, hosts already support MLD/IGMP in order to join multicast
groups, so why require them to run a routing protocol?
Brian
[EMAIL PROTECTED]
Pekka Savola wrote:
On Thu, 2 May 2002, Brian Haberman wrote:
Pekka Savola wrote:
On Thu, 2 May 2002, Brian Haberman wrote:
I had actually started taking a crack at this whole problem. It
seems to me that the following components are needed for some form of
global
Charlie,
I had actually started taking a crack at this whole problem. It
seems to me that the following components are needed for some form of
global anycast support:
1. Host-to-router notification protocol (this is taken care of by
changes to mld proposed in
Pekka,
Pekka Savola wrote:
On Thu, 2 May 2002, Brian Haberman wrote:
I had actually started taking a crack at this whole problem. It
seems to me that the following components are needed for some form of
global anycast support:
1. Host-to-router notification protocol
Rob,
Rob Austein wrote:
In the anycast model, you're at the mercy of the system that's
maintaining the anycast route: you can't query directly to find out
where the DNS server is, you have to wait for the routing system to
figure it out, and the routing system doesn't tell you when it
The original anycast extensions draft was incorporated into the
MLDv2 draft (draft-vida-mld-v2-02.txt) which is a MAGMA WG
document.
Regards,
Brian
Ralph Droms wrote:
Are the MLD extensions for anycast written up somewhere?
- Ralph
At 03:56 PM 4/30/2002 +0200, Hesham Soliman (ERA)
Rob,
Rob Austein wrote:
At Tue, 30 Apr 2002 08:07:14 -0400, Brian Haberman wrote:
Actually that is an incorrect statement. The IPv6 addressing
architecture forbids the use of an anycast address as the source
address. So, the response back from the anycast member will have
one
Steve Deering wrote:
At 12:29 PM +0900 3/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
wrote:
Perhaps we have two choices:
1. treat :: as global
2. does (explicitly) not define the scope type (level) of ::
Even the choice 2 will make the document clear, and it will
.? Obviously the other way is
not valid?
Thanks
KAT.Murugan
-Original Message-
From: Bound, Jim [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 19 March 2002 9:04 PM
To: Brian Haberman
Cc: [EMAIL PROTECTED]; IPng List
Subject: RE: Dual stack routers
Brian,
Agree. The entire issue
Dave Thaler wrote:
Antonio Querubin writes:
If it is how about just defining mapped multicast addresses already?
[...]
|80 bits | 16 | 32 bits|
+--+--+
Jim,
I agree with your assessment. It is essentially the way I have
integrated IPv6 into an IPv4 system. One point to keep in mind though
is how to support site-scoped addresses in this model. The route table
needs expansion in order to incorporate the zone IDs in the lookup.
Regards,
Ralph,
I agree the text should be updated. To address your points 'c'
and 'd', it should be pointed out that 2462 was written so that there
was no dependency upon a particular stateful configuration protocol.
Operators would simply utilize their protocol of choice (DHCPv6 or foo)
and 2462
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification, RFC 2463, December 1998.
Authors' Addresses
Brian Haberman
[EMAIL PROTECTED]
Jim Martin
[EMAIL PROTECTED]
Haberman, Martin
Margaret,
Margaret Wasserman wrote:
Before folks go and do a lot of additional work to update
draft-ietf-ipv6-cellular-host-00.txt based on our discussions,
I think we have to answer a fundamental question:
Should the WG publish an informational RFC detailing the IPv6
requirements for
John,
Since I have already voiced an agreement with Margaret's
suggestion, let me explain my rationale. Your document is a
mix of:
1. Host requirements (granted they are limited functionality hosts)
2. IPv6 over cellular links requirements
I believe that #2 is important as a
1 - 100 of 134 matches
Mail list logo
