[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for
From: "Peter Tam" <ptam () nortelnetworks ! com>
Date: 2000-06-30 18:05:27
[Download RAW message or body]
Alex: Please see inserts.... Peter
-----Original Message-----
From: Alex Conta [SMTP:aconta@txc.com]
Sent: Thursday, June 29, 2000 11:13 AM
To: Tam, Peter [NORSE:6L73:EXCH]
Cc: Bob Hinden; ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "Extensions to IPv6 Neighbor
Discovery for Inverse Discovery Specification"
Peter,
Thank you for your comments, which are important for the improving
of
this specification.
For the first comment, I need more clarification, but it is probably
better if I take the comments and answer them one by one, so please
see
bellow:
Peter Tam wrote:
>
>
> Bob:
>
> This is the 1st time I read this draft. Apology if the following
have
> been discussed before:
>
> 1. Must the Target Address List option in the Inverse Neighbor
> Discovery Advertisement (InvNDA) message not contain unicast
IPv6
> addresses only? I think it must. Then it will affect section
> 4.3.2 on the validation procedures.
>
Would you please elaborate?
>> Currently, the draft does not restrict the types of addresses
within the Source/Target Address Lists in the IND Solicitation/Advertisement
messages. Thus, it implies that both unicast and multicast addresses are
legitimate. This address information is used to build the Neighbor cache,
which I believe can contain only unicast addresses. If unicast-only
addresses are imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should
discard IND messages containing multicast addresses, so that they will not
be entered into the cache. After all, resolution should be between link
layer addresses and unicast network addresses.
> 1. Should it not also support unsolicited InvNDA, when 1 or more
of
> an inteface's IP addresses have been changed? It should, and
> should also enforce to re-advertise all the addresses on that
> interface. Otherwise, it is not possible to cover the
scenario
> where an IP address on the interface was deleted.
>
The motivations to the present text in the specification were the
following:
1. Minimizing and possibly eliminating unsolicited messages is a
good
thing.
2. The scenario in which one or more new IPv6 address are added to
an
existent VC can be solved by having the node adding such addresses
send
IND Solicitation(s).
3. The scenario in which one ore more IPv6 addresses associated with
a
VC are deleted while the VC and DLCI remain was envisaged to happen
seldom - more often, the VC and DLCI would be torn down as well -
and
be resolved through the IPv6 address deprecation.
>> There are 2 possible ways of providing changed IP address (added
or deleted) information using IND. First way is for the node that changes
its IP address(es) to use an unsolicited IND Advertisement message to
identify all the source IP addresses on that interface. The 2nd is for that
node to use an IND Solicitation message to identify all the source IP
addresses. The IND advertisement approach would have to add an S-bit to the
advertisement message, changing message format in the current draft. But it
involves 1 message type, the Advertisement. Secondly, the IND solicitation
approach does not change the current message formats, but will double the
amount of IND traffic with an advertisement response. Need only 1 approach.
> 1. Appendix A: Frame Relay (FR) as a link-layer address. But it
> should have a note up front that the DLCI applies to the
member
> DLCI in the case of a Multi-link Frame Relay.
>
The appendix was intended to contain one simple example to
illustrate
the use of the protocol. Some particular details of the link in the
example were considered out of scope.
>> Out-of/in scope is an artificial line. In this case, all it takes
is only 1 line of clarification.
> 1. Why is there a preference of FR to ATM in Appendix A? Should
also
> include the case for ATM as a link-layer technology.
>
>
As said previously, the appendix contains just one example, to
illustrate simply and briefly the use of the protocol. Although it
is
mentioned that it may apply to other link technologies, it was not
intended to cover more or all possible link technologies.
>> Yes, I agree. 1 scenario is as good as 2 or 3 if they are
similar. Moreover, you did indeed state the intent in the Abstract. Also, I
am a FR supporter.
>
>
> Regards... Peter Tam,
> Nortel Networks, Ottawa
Thank you,
Alex Conta
Transwitch Corporation, Shelton, CT
>
>
> -----Original Message-----
> From: Bob Hinden [SMTP:hinden@iprg.nokia.com]
> Sent: Thursday, June 22, 2000 4:27 PM
> To: ipng@sunroof.eng.sun.com
> Subject: W.G. Last Call on "Extensions to IPv6
Neighbor
> Discovery for Inverse Discovery Specification"
>
> This is a IPng working group last call for comments on
advancing
> the
> following document as a Proposed Standard:
>
> Title : Extensions to IPv6 Neighbor
Discovery
> for Inverse
> Discovery Specification
> Author(s) : A. Conta
> Filename : draft-ietf-ion-ipv6-ind-03.txt
> Pages : 22
> Date : 27-Oct-99
>
> Please send substantive comments to the ipng mailing list,
and
> minor
> editorial comments to the author. This last call period will
end
> two
> week from today on July 6, 2000.
>
> Bob Hinden / Steve Deering
>
>
>
-------------------------------------------------------------------
>
> 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
> majordomo@sunroof.eng.sun.com
>
>
-------------------------------------------------------------------
>
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse \
Discovery Specification"</TITLE> </HEAD>
<BODY>
<P><FONT SIZE=2 FACE="Arial">Alex: Please see inserts.... Peter</FONT>
</P>
<UL>
<P><A NAME="_MailData"><FONT SIZE=2 FACE="Arial">-----Original \
Message-----</FONT></A> <BR><B><FONT SIZE=2 FACE="Arial">From: Alex Conta \
[SMTP:aconta@txc.com]</FONT></B> <BR><B><FONT SIZE=2 \
FACE="Arial">Sent: </FONT></B> <FONT SIZE=2 FACE="Arial">Thursday, June \
29, 2000 11:13 AM</FONT> <BR><B><FONT SIZE=2 \
FACE="Arial">To: </FONT></B> <FONT SIZE=2 FACE="Arial">Tam, \
Peter [NORSE:6L73:EXCH]</FONT> <BR><B><FONT SIZE=2 \
FACE="Arial">Cc: </FONT></B> <FONT SIZE=2 FACE="Arial">Bob \
Hinden; ipng@sunroof.eng.sun.com</FONT> <BR><B><FONT SIZE=2 \
FACE="Arial">Subject: </FONT></B> <FONT \
SIZE=2 FACE="Arial">Re: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery \
for Inverse Discovery Specification"</FONT> </P>
<P><FONT SIZE=2 FACE="Arial">Peter,</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Thank you for your comments, which are important for the \
improving of</FONT> <BR><FONT SIZE=2 FACE="Arial">this specification.</FONT>
<BR><FONT SIZE=2 FACE="Arial">For the first comment, I need more clarification, but \
it is probably</FONT> <BR><FONT SIZE=2 FACE="Arial">better if I take the comments and \
answer them one by one, so please see</FONT> <BR><FONT SIZE=2 \
FACE="Arial">bellow:</FONT> </P>
<P><FONT SIZE=2 FACE="Arial">Peter Tam wrote:</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> Bob:</FONT>
<BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> This is the 1st time I read this draft. Apology if \
the following have</FONT> <BR><FONT SIZE=2 FACE="Arial">> been discussed \
before:</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> 1. Must the Target Address List option \
in the Inverse Neighbor</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> Discovery Advertisement (InvNDA) \
message not contain unicast IPv6</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> addresses only? I think it must. Then \
it will affect section</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> 4.3.2 on the validation \
procedures.</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Would you please elaborate?</FONT><U></U>
<BR><U><FONT SIZE=2 FACE="Arial">>> Currently, the draft does \
not</FONT></U><U><FONT SIZE=2 FACE="Arial"> restrict</FONT></U><U><FONT SIZE=2 \
FACE="Arial"> the</FONT></U><U> <FONT SIZE=2 FACE="Arial">types</FONT></U><U><FONT \
SIZE=2 FACE="Arial"></FONT></U><U> <FONT SIZE=2 FACE="Arial">of \
addresses</FONT></U><U> <FONT SIZE=2 FACE="Arial">within</FONT></U><U><FONT SIZE=2 \
FACE="Arial"> the</FONT></U><U> <FONT SIZE=2 FACE="Arial">Source/</FONT></U><U><FONT \
SIZE=2 FACE="Arial">Target Address List</FONT></U><U><FONT SIZE=2 FACE="Arial">s in \
the</FONT></U><U> <FONT SIZE=2 FACE="Arial">IND</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">Solicitation/</FONT></U><U><FONT SIZE=2 FACE="Arial">Advertisement \
messages.</FONT></U><U> <FONT SIZE=2 FACE="Arial">Thus, it implies that both unicast \
and multicast addresses are legitimate. Th</FONT></U><U><FONT SIZE=2 \
FACE="Arial">is</FONT></U><U> <FONT SIZE=2 FACE="Arial">address</FONT></U><U> <FONT \
SIZE=2 FACE="Arial">information</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">is</FONT></U><U><FONT SIZE=2 FACE="Arial"> used to build the Neighbor \
cache, which I believe</FONT></U><U> <FONT SIZE=2 FACE="Arial">can contain \
only</FONT></U><U><FONT SIZE=2 FACE="Arial"> unicast addresses. If \
unicast</FONT></U><U><FONT SIZE=2 FACE="Arial">-only</FONT></U><U><FONT SIZE=2 \
FACE="Arial"> addresses are imposed (</FONT></U><U><FONT SIZE=2 FACE="Arial">as I \
suggested), then</FONT></U><U> <FONT SIZE=2 FACE="Arial">Sections 4.3.1 and 4.3.2 \
should</FONT></U><U> <FONT SIZE=2 FACE="Arial">discard</FONT></U><U><FONT SIZE=2 \
FACE="Arial"> IND messages containing multicast addresses, so that they will \
not</FONT></U><U> <FONT SIZE=2 FACE="Arial">be entered into the \
cache.</FONT></U><U><FONT SIZE=2 FACE="Arial"> After all,</FONT></U><U><FONT SIZE=2 \
FACE="Arial"> resolution</FONT></U><U><FONT SIZE=2 FACE="Arial"></FONT></U><U> <FONT \
SIZE=2 FACE="Arial">should be between</FONT></U><U><FONT SIZE=2 FACE="Arial"> \
link</FONT></U><U> <FONT SIZE=2 FACE="Arial">layer</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">addresses and</FONT></U><U> <FONT SIZE=2 FACE="Arial">unicast network \
addresses.</FONT></U><U></U></P> <BR>
<P><FONT SIZE=2 FACE="Arial">> 1. Should it not also support \
unsolicited InvNDA, when 1 or more of</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> an inteface's IP addresses have been \
changed? It should, and</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> should also enforce to re-advertise \
all the addresses on that</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> interface. Otherwise, it is not \
possible to cover the scenario</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> where an IP address on the interface \
was deleted.</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">The motivations to the present text in the \
specification were the</FONT> <BR><FONT SIZE=2 FACE="Arial">following:</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">1. Minimizing and possibly eliminating unsolicited \
messages is a good</FONT> <BR><FONT SIZE=2 FACE="Arial">thing.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">2. The scenario in which one or more new IPv6 address \
are added to an</FONT> <BR><FONT SIZE=2 FACE="Arial">existent VC can be solved by \
having the node adding such addresses send</FONT> <BR><FONT SIZE=2 FACE="Arial">IND \
Solicitation(s).</FONT> </P>
<P><FONT SIZE=2 FACE="Arial">3. The scenario in which one ore more IPv6 addresses \
associated with a</FONT> <BR><FONT SIZE=2 FACE="Arial">VC are deleted while the VC \
and DLCI remain was envisaged to happen</FONT> <BR><FONT SIZE=2 FACE="Arial">seldom - \
more often, the VC and DLCI would be torn down as well - and</FONT> \
<BR><FONT SIZE=2 FACE="Arial">be resolved through the IPv6 address \
deprecation.</FONT><U></U> </P>
<P><U><FONT SIZE=2 FACE="Arial">>></FONT></U><U> <FONT SIZE=2 \
FACE="Arial">There are</FONT></U><U><FONT SIZE=2 FACE="Arial"></FONT></U><U> <FONT \
SIZE=2 FACE="Arial">2 possible ways of</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">providing</FONT></U><U><FONT SIZE=2 FACE="Arial"> changed IP address \
(added or deleted) information using IND</FONT></U><U><FONT SIZE=2 FACE="Arial">. \
First way is</FONT></U><U> <FONT SIZE=2 FACE="Arial">for the node that changes its IP \
address(es)</FONT></U><U><FONT SIZE=2 FACE="Arial"> to</FONT></U><U><FONT SIZE=2 \
FACE="Arial"></FONT></U><U> <FONT SIZE=2 FACE="Arial">use</FONT></U><U><FONT SIZE=2 \
FACE="Arial"> an unsolicited IND</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">A</FONT></U><U><FONT SIZE=2 FACE="Arial">dvertisement message to \
identify all the</FONT></U><U> <FONT SIZE=2 FACE="Arial">source</FONT></U><U> <FONT \
SIZE=2 FACE="Arial">IP addresses on that interface. The 2</FONT></U><U><SUP><FONT \
SIZE=2 FACE="Arial">nd</FONT></SUP></U><U><FONT SIZE=2 FACE="Arial"></FONT></U><U> \
<FONT SIZE=2 FACE="Arial">is</FONT></U><U><FONT SIZE=2 FACE="Arial"> for that \
node</FONT></U><U><FONT SIZE=2 FACE="Arial"> to use an IND</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">S</FONT></U><U><FONT SIZE=2 FACE="Arial">olicit</FONT></U><U><FONT \
SIZE=2 FACE="Arial">ation</FONT></U><U><FONT SIZE=2 FACE="Arial"> message to identify \
all the source IP addresses. The IND advertisement a</FONT></U><U><FONT SIZE=2 \
FACE="Arial">pproach would have to</FONT></U><U><FONT SIZE=2 FACE="Arial"> add an \
S-bit to</FONT></U><U><FONT SIZE=2 FACE="Arial"> the advertisement \
message</FONT></U><U><FONT SIZE=2 FACE="Arial">, changing</FONT></U><U><FONT SIZE=2 \
FACE="Arial"></FONT></U><U> <FONT SIZE=2 FACE="Arial">message format in</FONT></U><U> \
<FONT SIZE=2 FACE="Arial">the current draft</FONT></U><U><FONT SIZE=2 \
FACE="Arial">.</FONT></U><U> <FONT SIZE=2 FACE="Arial">But it involves 1 message \
type, the Advertisement.</FONT></U><U> <FONT SIZE=2 FACE="Arial">Secondly, \
t</FONT></U><U><FONT SIZE=2 FACE="Arial">he IND solicitation approach does not change \
the current message</FONT></U><U><FONT SIZE=2 FACE="Arial"> \
formats</FONT></U><U><FONT SIZE=2 FACE="Arial">, but</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">will double the amount of IND traffic with an advertisement \
response</FONT></U><U><FONT SIZE=2 FACE="Arial">.</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">Need only 1 app</FONT></U><U><FONT SIZE=2 \
FACE="Arial">roach.</FONT></U></P>
<P><FONT SIZE=2 FACE="Arial">> 1. Appendix A: Frame Relay (FR) as a \
link-layer address. But it</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> should have a note up front that the \
DLCI applies to the member</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> DLCI in the case of a Multi-link \
Frame Relay.</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">The appendix was intended to contain one simple example \
to illustrate</FONT> <BR><FONT SIZE=2 FACE="Arial">the use of the protocol. Some \
particular details of the link in the</FONT> <BR><FONT SIZE=2 FACE="Arial">example \
were considered out of scope.</FONT><U></U> <BR><U><FONT SIZE=2 FACE="Arial">>> \
Out-of/in scope is an artificial line. In this case,</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">all</FONT></U><U> <FONT SIZE=2 FACE="Arial">it</FONT></U><U> <FONT \
SIZE=2 FACE="Arial">takes is</FONT></U><U><FONT SIZE=2 FACE="Arial"> only 1 line of \
clarification.</FONT></U> </P>
<BR>
<P><FONT SIZE=2 FACE="Arial">> 1. Why is there a preference of FR to \
ATM in Appendix A? Should also</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> include the case for ATM as a \
link-layer technology.</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">></FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">As said previously, the appendix contains just one \
example, to</FONT> <BR><FONT SIZE=2 FACE="Arial">illustrate simply and briefly the \
use of the protocol. Although it is</FONT> <BR><FONT SIZE=2 FACE="Arial">mentioned \
that it may apply to other link technologies, it was not</FONT> <BR><FONT SIZE=2 \
FACE="Arial">intended to cover more or all possible link technologies.</FONT><U></U> \
<BR><U><FONT SIZE=2 FACE="Arial">>> Yes, I agree. 1 scenario is as good as 2 or \
3 if they are similar. Moreover, you did indeed state</FONT></U><U> <FONT SIZE=2 \
FACE="Arial">the inten</FONT></U><U><FONT SIZE=2 FACE="Arial">t</FONT></U><U><FONT \
SIZE=2 FACE="Arial"> in the Abstract.</FONT></U><U> <FONT SIZE=2 FACE="Arial">Also, I \
am a FR supporter.</FONT></U></P>
<P><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> Regards... Peter Tam,</FONT>
<BR><FONT SIZE=2 FACE="Arial">> Nortel Networks, Ottawa</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Thank you,</FONT>
<BR><FONT SIZE=2 FACE="Arial">Alex Conta</FONT>
<BR><FONT SIZE=2 FACE="Arial">Transwitch Corporation, Shelton, CT</FONT>
</P>
<BR>
<P><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> -----Original \
Message-----</FONT> <BR><FONT SIZE=2 FACE="Arial">> \
From: Bob Hinden [SMTP:hinden@iprg.nokia.com]</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> Sent: Thursday, June 22, \
2000 4:27 PM</FONT> <BR><FONT SIZE=2 FACE="Arial">> \
To: ipng@sunroof.eng.sun.com</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> \
Subject: W.G. Last Call on "Extensions \
to IPv6 Neighbor</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> Discovery for Inverse Discovery \
Specification"</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> This is a IPng \
working group last call for comments on advancing</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> the</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> following document as a Proposed \
Standard:</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> \
Title : Extensions to \
IPv6 Neighbor Discovery</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> for Inverse</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> &nb \
sp; \
Discovery Specification</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> \
Author(s) : A. Conta</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> \
Filename : \
draft-ietf-ion-ipv6-ind-03.txt</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> \
Pages : 22</FONT> \
<BR><FONT SIZE=2 FACE="Arial">> \
Date : \
27-Oct-99</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> Please send \
substantive comments to the ipng mailing list, and</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> minor</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> editorial comments to the \
author. This last call period will end</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> two</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> week from today on July 6, \
2000.</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> Bob Hinden / Steve \
Deering</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> \
-------------------------------------------------------------------</FONT> <BR><FONT \
SIZE=2 FACE="Arial">></FONT> <BR><FONT SIZE=2 \
FACE="Arial">> IETF IPng Working Group Mailing \
List</FONT> <BR><FONT SIZE=2 FACE="Arial">> IPng \
Home Page:</FONT> <BR><FONT SIZE=2 FACE="Arial">> <A \
HREF="http://playground.sun.com/ipng" \
TARGET="_blank">http://playground.sun.com/ipng</A></FONT> <BR><FONT SIZE=2 \
FACE="Arial">> FTP archive:</FONT> <BR><FONT SIZE=2 \
FACE="Arial">> <A \
HREF="ftp://playground.sun.com/pub/ipng" \
TARGET="_blank">ftp://playground.sun.com/pub/ipng</A></FONT> <BR><FONT SIZE=2 \
FACE="Arial">> Direct all administrative requests \
to</FONT> <BR><FONT SIZE=2 FACE="Arial">> \
majordomo@sunroof.eng.sun.com</FONT> <BR><FONT SIZE=2 FACE="Arial">></FONT>
<BR><FONT SIZE=2 FACE="Arial">> \
-------------------------------------------------------------------</FONT> <BR><FONT \
SIZE=2 FACE="Arial">></FONT> <BR>
</P>
</UL>
</BODY>
</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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic