From owner-ipng@sunroof.eng.sun.com Tue Aug  1 09:41:08 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e71GdbW25059
	for ipng-dist; Tue, 1 Aug 2000 09:39:37 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71GdS625052
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 09:39:29 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07921
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 09:39:28 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA04331
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 09:39:24 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Aug 2000 09:35:55 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <QA2W55XM>; Tue, 1 Aug 2000 09:35:47 -0700
Message-ID: <4D0A23B3F74DD111ACCD00805F31D81025C71BF9@RED-MSG-50>
From: Richard Draves <richdr@microsoft.com>
To: JINMEI Tatuya / ???? <jinmei@isl.rdc.toshiba.co.jp>, tim@mentat.com
Cc: vlad@zk3.dec.com, aconta@txc.com, varadhan@zk3.dec.com, deering@cisco.com,
   ipng@sunroof.eng.sun.com
Subject: RE: Tunnel Encapsulation Limit Option in rfc2473
Date: Tue, 1 Aug 2000 09:33:38 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> > Continuing to insist that you haven't changed the 
> fragmentation rules is
> > not an accurate assessment of the situation once one 
> considers the details
> > of actual implementation.
> 
> (although we've never tried to implement the tunnel encapsulation
> option in the KAME statck) I completely agree with Tim and Vlad; the
> proposed rule for the new option contradicts with general rules
> described in RFC2460, and the advantage of the new rule is not worth
> modifying existing implementations (IMHO).

I'll agree with this also. This is a non-trivial & ugly change to the
fragmentation rules in RFC 2460.

It may be too late, but how about this idea - have two code points for the
Destination Options, one that indicates fragmentable Destination Options
(typically used after routing/fragment header) and one that indicates
non-fragmentable Destination Options (typically used before routing/fragment
header, or when there is a tunnel encapsulation option).

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug  1 09:46:37 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e71GjXU25082
	for ipng-dist; Tue, 1 Aug 2000 09:45:33 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71GjO625075
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 09:45:24 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA09387
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 09:45:23 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA07877
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 09:45:01 -0700 (PDT)
Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Aug 2000 09:33:12 -0700 (Pacific Daylight Time)
Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58)
	id <PGAJTBD8>; Tue, 1 Aug 2000 09:33:16 -0700
Message-ID: <4D0A23B3F74DD111ACCD00805F31D81025C71BF8@RED-MSG-50>
From: Richard Draves <richdr@microsoft.com>
To: Margaret Wasserman <mrw@epilogue.com>
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: RE: Scoped Addressing Architecture Routing Issue
Date: Tue, 1 Aug 2000 09:33:38 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> In the example that I gave, the network is not misconfigured.  
> There is intra-site routing for an entire site, and there is a 
> second site redundantly attached to the first site.
> 
> Are you implying that a mixed-scope packet always indicates
> a misconfigured network?

The mixed-scope packet is a strong indication of misconfiguration, since the
address selection rules try to avoid mixing scopes.

Your example also has the best route between H1 & H2 in site B, be to go
through site A. This seems really unlikely to occur in actual practice. You
seem to be implicitly assuming that the two sites are in a single IGP
routing domain.

> I agree that being able to debug network problems is good, but
> I think that it is less important than being able to successfully
> route packets to their destinations.

Here's another scenario, much more plausible in my opinion.

Suppose Site A is connected to the internet via site-border router R. Host H
is in site A. Destination D is out in the internet.

Router R is connected to two links. Link 1 is an ethernet inside site A.
Link 2 is a tunnel to some 6bone router; link 2 is not in site A. Router R
has a default route out link 2 plus some more specific routes out link 1,
for the global & site-local prefixes in use within site A.

Now host H sends a packet with a site-local source address and global
destination D. When this packet gets to R, you really want R to generate a
destination-unreachable / scope-exceeded ICMP error.

But with your proposal, that wouldn't happen. Instead R would constrain its
route table lookup to site A, so it would only consider routes out link 1.
It wouldn't find any routes matching the destination. Depending on the
implementation, R might generate a destination-unreachable /
no-route-to-destination ICMP error or, it might assume the destination D is
on-link to link 1 and initiate ND (RFC 2461 section 5.2 para 2 can be
construed this way), eventually generating a destination-unreachable /
address-unreachable ICMP error. Either way, the ICMP error would be pretty
confusing.

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug  1 11:12:08 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e71IA1j25123
	for ipng-dist; Tue, 1 Aug 2000 11:10:01 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71I9v625116
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 11:09:57 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA16973
	for ipng@sunroof.eng.sun.com; Tue, 1 Aug 2000 11:08:09 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71Dxh624987
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 06:59:44 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA21010
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 06:59:44 -0700 (PDT)
Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15679
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 06:59:43 -0700 (PDT)
Received: from wired-129-169.ietf.marconi.com ([147.73.129.169]:11012 "HELO kenawang" ident: "IDENT-NOT-QUERIED [port 11012]") by newquern.epilogue.com with SMTP id <653-175>; Tue, 1 Aug 2000 09:59:25 -0400
Message-Id: <4.2.2.20000801081732.01404060@localhost>
X-Sender: mrfpop@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
To: Richard Draves <richdr@microsoft.com>
From: Margaret Wasserman <mrw@epilogue.com>
Subject: RE: Scoped Addressing Architecture Routing Issue
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA222AC@RED-MSG-50>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: 	Tue, 1 Aug 2000 09:59:25 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


In the example that I gave, the network is not misconfigured.  
There is intra-site routing for an entire site, and there is a 
second site redundantly attached to the first site.

Are you implying that a mixed-scope packet always indicates
a misconfigured network?

I agree that being able to debug network problems is good, but
I think that it is less important than being able to successfully
route packets to their destinations.

Margaret





At 05:42 PM 7/31/00 -0400, Richard Draves wrote:
>I've thought some in the past about your proposal. It would mean, for
>example, that there would be no Destination Unreachable / Scope Exceeded
>ICMP error because the routing table lookup would be constrained so as to
>not exceed the scope of the source address.
>
>My conclusion was that in normal configurations, it wouldn't make a
>difference. But when a network is misconfigured, it would get in the way of
>debugging the problem because you wouldn't get the ICMP error.
>
>Rich
>
> > -----Original Message-----
> > From: Margaret Wasserman [mailto:mrw@epilogue.com]
> > Sent: Monday, July 31, 2000 12:26 PM
> > To: IPng Working Group
> > Subject: Scoped Addressing Architecture Routing Issue
> > 
> > 
> > 
> > I believe that there is a problem with the forwarding section
> > of the Scoped Addressing Architecture document (section 9).
> > 

[...]



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

From owner-ipng@sunroof.eng.sun.com Tue Aug  1 12:38:47 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e71JbAE25258
	for ipng-dist; Tue, 1 Aug 2000 12:37:10 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71Jb0625251
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 12:37:01 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA09799
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 12:37:00 -0700 (PDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03352
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 13:36:46 -0600 (MDT)
Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e71Jaiw17308
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 21:36:44 +0200 (MEST)
Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1);
	 Tue, 1 Aug 2000 21:36:43 +0200
Received: from esealnt172.ericsson.se ([130.100.184.165]) by 153.88.251.32
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 01 Aug 2000 19:36:43 0000 (GMT)
Received: by esealnt172 with Internet Mail Service (5.5.2651.58)
	id <PF1F4476>; Tue, 1 Aug 2000 21:35:36 +0200
Message-ID: <33C9100DDE98D211A16D0008C7A4E3FE0818EEA4@esealnt103>
From: "Scott Millington (BCT)" <Scott.Millington@edt.ericsson.se>
To: "'Margaret Wasserman'" <mrw@epilogue.com>,
   Richard Draves
	 <richdr@microsoft.com>
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: RE: Scoped Addressing Architecture Routing Issue
Date: Tue, 1 Aug 2000 21:36:40 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
X-OriginalArrivalTime: 01 Aug 2000 19:36:43.0813 (UTC) FILETIME=[D290E550:01BFFBEF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e71Jb2625252
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

WHOA!!!

Please, if we can't debug network problems then your applications won't work anyways.  Is correct, interpretable ICMP traffic too much to expect??

Remember you are to an extent engineering for the lowest common denominator...Not me, I am a god ;)

The people most in need of the ICMP function are the ones that get called in as consultants when the local gumby has made a mess...WE NEED THIS FUNCIONALITY!!

Sincerely,
Scott Millington
Data Communications Architect
+++++++++++++++++++++++++
Ericsson Infrastructure Services
Corporate Network - Basic EriNet
KI/BCT/I/ONF
Kistagången 4-4tr.
125 82 Stockholm
Telephone: +46-8-75 71667
Cellphone: +46-70-643 7897
Facsimile: +46-8-40 45550
EMAIL:  scott.millington@edt.ericsson.se
URL:    work - http://www.ericsson.se
        home - http://haapis.zap.to
+++++++++++++++++++++++++
Disclaimer: When I say something 
it is just me saying something 
and it is probably wrong anyway.
Certainly nothing I post should 
be construed as a statement of 
Ericsson company policy.


-----Original Message-----
From: Margaret Wasserman [mailto:mrw@epilogue.com]
Sent: 2000-08-01 15:59
To: Richard Draves
Cc: IPng Working Group
Subject: RE: Scoped Addressing Architecture Routing Issue



In the example that I gave, the network is not misconfigured.  
There is intra-site routing for an entire site, and there is a 
second site redundantly attached to the first site.

Are you implying that a mixed-scope packet always indicates
a misconfigured network?

I agree that being able to debug network problems is good, but
I think that it is less important than being able to successfully
route packets to their destinations.

Margaret





At 05:42 PM 7/31/00 -0400, Richard Draves wrote:
>I've thought some in the past about your proposal. It would mean, for
>example, that there would be no Destination Unreachable / Scope Exceeded
>ICMP error because the routing table lookup would be constrained so as to
>not exceed the scope of the source address.
>
>My conclusion was that in normal configurations, it wouldn't make a
>difference. But when a network is misconfigured, it would get in the way of
>debugging the problem because you wouldn't get the ICMP error.
>
>Rich
>
> > -----Original Message-----
> > From: Margaret Wasserman [mailto:mrw@epilogue.com]
> > Sent: Monday, July 31, 2000 12:26 PM
> > To: IPng Working Group
> > Subject: Scoped Addressing Architecture Routing Issue
> > 
> > 
> > 
> > I believe that there is a problem with the forwarding section
> > of the Scoped Addressing Architecture document (section 9).
> > 

[...]



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

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

From owner-ipng@sunroof.eng.sun.com Tue Aug  1 18:20:10 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e721Hta25458
	for ipng-dist; Tue, 1 Aug 2000 18:17:55 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e721Hh625451
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 18:17:43 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA02768
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 18:17:42 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA28114
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 19:17:42 -0600 (MDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 Aug 2000 18:16:41 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58)
	id <QA2FN8JK>; Tue, 1 Aug 2000 18:16:18 -0700
Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA222DB@RED-MSG-50>
From: Richard Draves <richdr@microsoft.com>
To: "'Margaret Wasserman'" <mrw@epilogue.com>
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: RE: Scoped Addressing Architecture Routing Issue
Date: Tue, 1 Aug 2000 18:16:15 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> >Your example also has the best route between H1 & H2 in site 
> B, be to go
> >through site A. This seems really unlikely to occur in 
> actual practice. You
> >seem to be implicitly assuming that the two sites are in a single IGP
> >routing domain.
> 
> I am assuming that two sites _may_ be in the same routing domain, and
> that problems could occur in that situation.  I don't believe that the
> current IPv6 specifications assume that a single routing domain will 
> always be a single site.  

It's not assumed, but I think it will be uncommon to have two sites in a
single IGP routing domain and when it does occur the admin will have to take
care to avoid bad results in situations like you described.

> My example packet could easily occur in response to a packet sent from
> a host that doesn't have a site-local address (perhaps because it was
> configured via DHCP?).  That host would need to use a global 
> address to 
> communicate with a site-local address, and the response would have
> a site-local source and a global destination.  

The address selection rules try really hard to avoid mixed-scope packets. It
will happen if there's a host that has a global address but no site-local
address trying to communicate with a host that has a site-local address but
no global address. I think the presence of a mixed-scoped packet generally
indicates some problem somewhere.

> The ICMP issue that you have described would also exist when using 
> multiple "conceptual" routing tables in the case of a partitioned 
> site.  For example:
> 
> ==========================================================
> SITEA
>        Host1                      Host2
>          |                          |
> ________|__.__._____  ____.______._|_____________
>    Link1    |  |           |      |     Link2
>             |  |          (down)  |        
>             |  +-----R1----+      |
>             |                     |
>             |                     |
> ===========|=====================|=========================
> SITEB      |                     |
>             +--------R1-----------+
> 
> ===========================================================
> 
> If a site-local packet (site-local destination and site-
> local source) is send from Host1 to Host2, it would
> probably be sent to the local router, R1.
> 
> R1 would then use the scoped addressing rules to forward the 
> packet.  First, he would look at the destination address
> to determine that he should look in the site-local table.
> The site-local table would have no active route to Link2,
> so he would send a Destination Unreachable/No Route 
> To Destination message, _not_ a Scope Exceeded message.

This sounds right... a link is down, so you get no-route-to-destination and
you know what to start looking for.

> In this case, it might actually be _useful_ for the sender 
> to receive a Scope Exceeded message, because the sender might 
> be able to switch to global communication.  The sender may 
> have had both site-local and global addresses available, but
> have chosen site-local communication.  But, he doesn't get the
> Scope Exceeded message, so he can't act on it.

If the sender is trying to open a TCP connection, and their user-level code
is smart enough to iterate through the destination addresses that it got
back from getaddrinfo(), then the sender will first try the site-local
destination (using its site-local source address) and then when that
connect() fails it will fall back to the global destination (using its
global source address). The ICMP error isn't relevant to this to because TCP
treats the ICMP errors as soft errors.

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 05:59:37 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e72CwFt25695
	for ipng-dist; Wed, 2 Aug 2000 05:58:15 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72Cw6625688
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 05:58:06 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA00896
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 05:58:07 -0700 (PDT)
Received: from webveda.com (host-216-226-254-55.interpacket.net [216.226.254.55])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA10341
	for <ipng@sunroof.eng.sun.com.>; Wed, 2 Aug 2000 05:58:06 -0700 (PDT)
Received: from webveda.com ([216.226.254.55]) by webveda.com ; Thu, 03 Aug 2000 02:56:55 -0400
From: "shankar" <ipng@webveda.com>
Reply-to: ipng@webveda.com
To: ipng@sunroof.eng.sun.com
Date: Wed, 02 Aug 2000 18:29:26 +0600
Subject: IPv6 -over-IPv4 tunnel.
X-Mailer: CWMail Web to Mail Gateway 2.5e, http://netwinsite.com/top_mail.htm
Message-id: <398917b7.2c47.0@webveda.com>
X-User-Info: 203.197.138.194
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi folks,

cant we treat the IPv4 layer incase of IPv6/IPv4 nodes as a 
tunnel interface, with the local, remote IPv4 addresses as the 
tunnel configurations i.e. can we apply the new tunnel mib 2667
to this concept of tunneling. 

here a tunnel interface will be created, and the IPv6 routing table will have
the IPv4 encap also as a interface. 

does that sound ok ?

tia
shankar
-------------------------------------------------
Make webveda your permanent address like i have.
Get 15 MB Free space only at http://www.webveda.com
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 08:29:08 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e72FRk425798
	for ipng-dist; Wed, 2 Aug 2000 08:27:46 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72FRc625791
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 08:27:38 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA27095
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 08:27:38 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29126
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 09:27:37 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA03263;
	Wed, 2 Aug 2000 08:27:36 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA07209;
	Wed, 2 Aug 2000 08:27:32 -0700
X-Virus-Scanned:  Wed, 2 Aug 2000 08:27:32 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from wired-129-36.ietf.marconi.com (147.73.129.36, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdH0x5rT; Wed, 02 Aug 2000 08:27:29 PDT
Message-Id: <4.3.2.7.2.20000802082247.025a7ae8@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 Aug 2000 08:27:14 -0700
To: ipng@sunroof.eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: IPv6 Implementation Reports
Cc: hinden@iprg.nokia.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

As part of moving the IPv6 over <link> documents to Draft Standard we need 
to collect implementation reports.  With considerable help from Matt 
Crawford I have created templates for an implementation report.  These can 
be found at:

   http://playground.sun.com/pub/ipng/implementation-reports/templates/

The templates for Ethernet, Token Ring, and FDDI.  The files names are of 
the form ipv6-over-<link>.txt.  If you have an implementation please fill 
out the template and send it to me.

Note: I am missing a template for IPv6 over ARCNET.  I will announce it 
when it is available.

At the same location there are also templates for IPv6, Addressing 
Architecture, Address Aggregation format, Path MTU, and ICMP.  If you have 
not submitted one previously, please do so.  The current implementation 
reports can be found at:

   http://playground.sun.com/pub/ipng/implementation-reports/

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 12:59:01 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e72Jq0o25961
	for ipng-dist; Wed, 2 Aug 2000 12:52:00 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72Jpn625954
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 12:51:49 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA01854
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 12:51:47 -0700 (PDT)
Received: from starfruit.itojun.org (wireless-132-108.ietf.marconi.com [147.73.132.108])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22083
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 13:51:43 -0600 (MDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by  starfruit.itojun.org (8.11.0/8.11.0) with ESMTP id e72JpWW02883;
	Thu, 3 Aug 2000 04:51:32 +0900 (JST)
Message-Id: <200008021951.e72JpWW02883@ starfruit.itojun.org>
To: ipng@sunroof.eng.sun.com
Subject: bind(2) ordering constraint
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <2867.965245746.0@localhost>
Date: Thu, 03 Aug 2000 04:51:32 +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2867.965245746.1@localhost>

	as you know, RFC2553 does not specify any ordering constraint on
	bind(2).  this has been source of confusion, as Dave@microsoft
	talked at IETF48 meeting.  BIND9 doc/misc/ipv6 talks about this issue
	in detail.

	implementers, please run the attached program, and send the result to
	me, or to the list, with clear indication of
	- platform (like "NetBSD")
	- version (like "1.5_ALPHA")
	- comments, and some background info/reasoning for your behavior
	sample result is attached.

	i will compile the results got from you guys, and present that to
	the list.  i'm not sure if we can reach consensus about this,
	but i think we should at least document existing behavior,
	to help people like BIND9 implementers.

itojun


------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2867.965245746.2@localhost>

NetBSD starfruit.itojun.org 1.5C NetBSD 1.5C (STARFRUIT) #83: Wed Aug  2 21:02:32 JST 2000     itojun@starfruit.itojun.org:/usr/home/itojun/NetBSD/src/sys/arch/i386/compile/STARFRUIT i386

- IPv4 mapped address on AF_INET6 is, in most cases, prohibited.
  this is to avoid possible security issues with it.
- there is no ordering constraint between AF_INET wildcard bind(2) and AF_INET6
  wildcard bind(2).
  this is because we consider AF_INET wildcard as "more specific address"
  than AF_INET6 wildcard, and we usually permit "more specific address" bind(2).

---
starting tests, socktype = SOCK_DGRAM
wild4 then wild4
	bind socket for 0.0.0.0/9999
	bind socket for 0.0.0.0/9999
	failed bind for 0.0.0.0/9999, Address already in use
wild4 then wild6
	bind socket for 0.0.0.0/9999
	bind socket for ::/9999
wild4 then loop4
	bind socket for 0.0.0.0/9999
	bind socket for 127.0.0.1/9999
	failed bind for 127.0.0.1/9999, Address already in use
wild4 then loop6
	bind socket for 0.0.0.0/9999
	bind socket for ::1/9999
wild4 then one4
	bind socket for 0.0.0.0/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
wild4 then map4
	bind socket for 0.0.0.0/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
wild6 then wild4
	bind socket for ::/9999
	bind socket for 0.0.0.0/9999
wild6 then wild6
	bind socket for ::/9999
	bind socket for ::/9999
	failed bind for ::/9999, Address already in use
wild6 then loop4
	bind socket for ::/9999
	bind socket for 127.0.0.1/9999
wild6 then loop6
	bind socket for ::/9999
	bind socket for ::1/9999
	failed bind for ::1/9999, Address already in use
wild6 then one4
	bind socket for ::/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
wild6 then map4
	bind socket for ::/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
loop4 then wild4
	bind socket for 127.0.0.1/9999
	bind socket for 0.0.0.0/9999
	failed bind for 0.0.0.0/9999, Address already in use
loop4 then wild6
	bind socket for 127.0.0.1/9999
	bind socket for ::/9999
loop4 then loop4
	bind socket for 127.0.0.1/9999
	bind socket for 127.0.0.1/9999
	failed bind for 127.0.0.1/9999, Address already in use
loop4 then loop6
	bind socket for 127.0.0.1/9999
	bind socket for ::1/9999
loop4 then one4
	bind socket for 127.0.0.1/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
loop4 then map4
	bind socket for 127.0.0.1/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
loop6 then wild4
	bind socket for ::1/9999
	bind socket for 0.0.0.0/9999
loop6 then wild6
	bind socket for ::1/9999
	bind socket for ::/9999
	failed bind for ::/9999, Address already in use
loop6 then loop4
	bind socket for ::1/9999
	bind socket for 127.0.0.1/9999
loop6 then loop6
	bind socket for ::1/9999
	bind socket for ::1/9999
	failed bind for ::1/9999, Address already in use
loop6 then one4
	bind socket for ::1/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
loop6 then map4
	bind socket for ::1/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
one4 then wild4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then wild6
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then loop4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then loop6
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then one4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then map4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
map4 then wild4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
map4 then wild6
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
map4 then loop4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
map4 then loop6
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
map4 then one4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address
map4 then map4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested address

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2867.965245746.3@localhost>

/*
 * Copyright (C) 1999 WIDE Project.
 * All rights reserved.
 * 
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. Neither the name of the project nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without loop prior written permission.
 * 
 * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 */
/*
 * $Id: bindtest.c,v 1.8 1999/10/06 08:10:05 itojun Exp $
 */

#include <sys/types.h>
#include <sys/socket.h>
#include <sys/param.h>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <netdb.h>
#include <errno.h>
#include <err.h>

#include <netinet/in.h>

int main __P((int, char **));
static void usage __P((void));
static struct addrinfo *getres __P((int, const char *, const char *));
static const char *printres __P((struct addrinfo *));
static int test __P((const char *, struct addrinfo *, struct addrinfo *));

static struct addrinfo *wild4, *wild6;
static struct addrinfo *loop4, *loop6;
static struct addrinfo *one4, *map4;
static char *port = NULL;
static int socktype = SOCK_DGRAM;

int
main(argc, argv)
	int argc;
	char **argv;
{
	int ch;
	extern int optind;
	extern char *optarg;

	while ((ch = getopt(argc, argv, "p:t")) != EOF) {
		switch (ch) {
		case 'p':
			port = strdup(optarg);
			break;
		case 't':
			socktype = SOCK_STREAM;
			break;
		default:
			usage();
			exit(1);
		}
	}

#if 0
	if (port == NULL)
		port = allocport();
#endif

	if (port == NULL) {
		errx(1, "no port specified");
		/*NOTREACHED*/
	}

	wild4 = getres(AF_INET, NULL, port);
	wild6 = getres(AF_INET6, NULL, port);
	loop4 = getres(AF_INET, "127.0.0.1", port);
	loop6 = getres(AF_INET6, "::1", port);
	one4 = getres(AF_INET, "0.0.0.1", port);
	map4 = getres(AF_INET6, "::ffff:127.0.0.1", port);

	printf("starting tests, socktype = %s\n",
		socktype == SOCK_DGRAM ? "SOCK_DGRAM" : "SOCK_STREAM");
#define TESTIT(x, y)	test(#x " then " #y, (x), (y))
#define TESTALL(x) \
do { \
	TESTIT(x, wild4); \
	TESTIT(x, wild6); \
	TESTIT(x, loop4); \
	TESTIT(x, loop6); \
	TESTIT(x, one4); \
	TESTIT(x, map4); \
} while (0)

	TESTALL(wild4);
	TESTALL(wild6);
	TESTALL(loop4);
	TESTALL(loop6);
	TESTALL(one4);
	TESTALL(map4);

	exit(0);
}

static void
usage()
{
	fprintf(stderr, "usage: bindtest [-t] -p port\n");
}

static struct addrinfo *
getres(af, host, port)
	int af;
	const char *host;
	const char *port;
{
	struct addrinfo hints, *res;
	int error;

	memset(&hints, 0, sizeof(hints));
	hints.ai_family = af;
	hints.ai_socktype = socktype;
	hints.ai_flags = AI_PASSIVE;
	error = getaddrinfo(host, port, &hints, &res);
	return res;
}

static const char *
printres(res)
	struct addrinfo *res;
{
	char hbuf[MAXHOSTNAMELEN], pbuf[10];
	static char buf[sizeof(hbuf) + sizeof(pbuf)];

	getnameinfo(res->ai_addr, res->ai_addrlen, hbuf, sizeof(hbuf),
		pbuf, sizeof(pbuf), NI_NUMERICHOST | NI_NUMERICSERV);
	snprintf(buf, sizeof(buf), "%s/%s", hbuf, pbuf);
	return buf;
}

static int
test(title, a, b)
	const char *title;
	struct addrinfo *a;
	struct addrinfo *b;
{
	int sa = -1, sb = -1;

	printf("%s\n", title);

#if 0
	printf("\tallocating socket for %s\n", printres(a));
#endif
	sa = socket(a->ai_family, a->ai_socktype, a->ai_protocol);
	if (sa < 0) {
		printf("\tfailed socket for %s, %s\n",
			printres(a), strerror(errno));
		goto fail;
	}
#if 0
	printf("\tallocating socket for %s\n", printres(b));
#endif
	sb = socket(b->ai_family, b->ai_socktype, b->ai_protocol);
	if (sb < 0) {
		printf("\tfailed socket for %s, %s\n",
			printres(b), strerror(errno));
		goto fail;
	}

	printf("\tbind socket for %s\n", printres(a));
	if (bind(sa, a->ai_addr, a->ai_addrlen) < 0) {
		printf("\tfailed bind for %s, %s\n",
			printres(a), strerror(errno));
		goto fail;
	}

	printf("\tbind socket for %s\n", printres(b));
	if (bind(sb, b->ai_addr, b->ai_addrlen) < 0) {
		printf("\tfailed bind for %s, %s\n",
			printres(b), strerror(errno));
		goto fail;
	}

	if (sa >= 0)
		close(sa);
	if (sb >= 0)
		close(sb);
	return 0;

fail:
	if (sa >= 0)
		close(sa);
	if (sb >= 0)
		close(sb);
	return -1;
}

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2867.965245746.4@localhost>

.\" Copyright (C) 1999 WIDE Project.
.\" All rights reserved.
.\" 
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. Neither the name of the project nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\" 
.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"     $Id: bindtest.1,v 1.4 2000/01/19 06:24:51 itojun Exp $
.\"
.Dd October 6, 1999
.Dt BINDTEST 1
.Os KAME
.\"
.Sh NAME
.Nm bindtest
.Nd test bind(2) behavior on IPv6 implementation
.\"
.Sh SYNOPSIS
.Nm
.Op Fl t
.Fl p Ar port
.\"
.Sh DESCRIPTION
.Nm
tests interaction between IPv4/IPv6 socket interface, implemented into
the kernel it has underneath.
.Pp
RFC2553 defines socket API for IPv6, and relationship between
IPv6 wildcard
.Xr bind 2
socket
.Pq Li ::.port
and IPv4 wildcard
.Xr bind 2
socket
.Pq Li 0.0.0.0.port .
However, the document does not define ordering constraints between them,
relationship with specific
.Xr bind 2 ,
nor relationship with speficfic
.Xr bind 2
using IPv4 mapped IPv6 address
.Pq Li ::ffff:127.0.0.1 .
.Pp
.Nm
tries to reveal the behavior implemented in the kernel,
and shows some report to standard output.
As RFC2553 does not define the expected behavior,
we have no idea what the result should be.
.Pp
By default
.Nm
will use
.Dv SOCK_DGRAM
socket for testing.
With
.Fl t ,
.Nm
will use
.Dv SOCK_STREAM
socket instead.
TCP/UDP port number must be specified with
.Fl p Ar port .
The
.Ar port
needs to be vacant.
.\"
.Sh RETURN VALUES
.Nm
exits with 0 on success, and non-zero on errors.
.\"
.Sh SEE ALSO
.Rs
.%A R. Gilligan
.%A S. Thomson
.%A J. Bound
.%A W. Stevens
.%T Basic Socket Interface Extensions for IPv6
.%D March 1999
.%N RFC2553
.Re
.Pp
.Xr bind 2 ,
.Xr tcpdump 8
.\"
.Sh HISTORY
The
.Nm
command first appeared in WIDE/KAME IPv6 protocol stack kit.

------- =_aaaaaaaaaa0--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 16:59:04 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e72Nvf626148
	for ipng-dist; Wed, 2 Aug 2000 16:57:41 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72NvW626141
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 16:57:33 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA00090
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 16:57:33 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17810
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 16:57:33 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA26783;
	Wed, 2 Aug 2000 16:57:33 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id QAA30534;
	Wed, 2 Aug 2000 16:57:30 -0700
X-Virus-Scanned:  Wed, 2 Aug 2000 16:57:30 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from wired-128-126.ietf.marconi.com (147.73.128.126, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdYnIpRx; Wed, 02 Aug 2000 16:57:22 PDT
Message-Id: <4.3.2.7.2.20000802142016.02178610@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 Aug 2000 14:23:55 -0700
To: ipng@sunroof.eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: W.G. Last Call on "IPv6 Node Information Queries"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a IPng 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-06.txt 	
	Pages : 14
	Date : 20-Jul-00

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 August 16, 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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 17:35:51 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e730YP826211
	for ipng-dist; Wed, 2 Aug 2000 17:34:25 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e730YG626204
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 17:34:16 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA15053
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 17:34:16 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA12575
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 18:34:15 -0600 (MDT)
Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 Aug 2000 16:54:24 -0700 (Pacific Daylight Time)
Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023);
	 Wed, 2 Aug 2000 17:03:50 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.4415.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFFCDE.2B26C0C4"
Subject: RE: IPv6 -over-IPv4 tunnel.
Date: Wed, 2 Aug 2000 17:02:52 -0700
Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CF033@SIT.platinum.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPv6 -over-IPv4 tunnel.
Thread-Index: Ab/8gaWU6OVyVl6LSzC/iPmJUg8I6AAXIL0g
From: "Dave Thaler" <dthaler@Exchange.Microsoft.com>
To: <ipng@webveda.com>, <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 03 Aug 2000 00:03:50.0783 (UTC) FILETIME=[4DCC30F0:01BFFCDE]
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFFCDE.2B26C0C4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Yes, that was one of the intents of RFC 2667.

-Dave

-----Original Message-----
From: shankar [mailto:ipng@webveda.com]
Sent: Wednesday, August 02, 2000 8:29 AM
To: ipng@sunroof.eng.sun.com
Subject: IPv6 -over-IPv4 tunnel.


Hi folks,

cant we treat the IPv4 layer incase of IPv6/IPv4 nodes as a=20
tunnel interface, with the local, remote IPv4 addresses as the=20
tunnel configurations i.e. can we apply the new tunnel mib 2667
to this concept of tunneling.=20

here a tunnel interface will be created, and the IPv6 routing table will
have
the IPv4 encap also as a interface.=20

does that sound ok ?

tia
shankar
-------------------------------------------------
Make webveda your permanent address like i have.
Get 15 MB Free space only at http://www.webveda.com
--------------------------------------------------------------------
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
--------------------------------------------------------------------

------_=_NextPart_001_01BFFCDE.2B26C0C4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4415.0">
<TITLE>RE: IPv6 -over-IPv4 tunnel.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Yes, that was one of the intents of RFC 2667.</FONT>
</P>

<P><FONT SIZE=3D2>-Dave</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>

<BR><FONT SIZE=3D2>From: shankar [<A =
HREF=3D"mailto:ipng@webveda.com">mailto:ipng@webveda.com</A>]</FONT>

<BR><FONT SIZE=3D2>Sent: Wednesday, August 02, 2000 8:29 AM</FONT>

<BR><FONT SIZE=3D2>To: ipng@sunroof.eng.sun.com</FONT>

<BR><FONT SIZE=3D2>Subject: IPv6 -over-IPv4 tunnel.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi folks,</FONT>
</P>

<P><FONT SIZE=3D2>cant we treat the IPv4 layer incase of IPv6/IPv4 nodes =
as a </FONT>

<BR><FONT SIZE=3D2>tunnel interface, with the local, remote IPv4 =
addresses as the </FONT>

<BR><FONT SIZE=3D2>tunnel configurations i.e. can we apply the new =
tunnel mib 2667</FONT>

<BR><FONT SIZE=3D2>to this concept of tunneling. </FONT>
</P>

<P><FONT SIZE=3D2>here a tunnel interface will be created, and the IPv6 =
routing table will have</FONT>

<BR><FONT SIZE=3D2>the IPv4 encap also as a interface. </FONT>
</P>

<P><FONT SIZE=3D2>does that sound ok ?</FONT>
</P>

<P><FONT SIZE=3D2>tia</FONT>

<BR><FONT SIZE=3D2>shankar</FONT>

<BR><FONT =
SIZE=3D2>-------------------------------------------------</FONT>

<BR><FONT SIZE=3D2>Make webveda your permanent address like i =
have.</FONT>

<BR><FONT SIZE=3D2>Get 15 MB Free space only at <A =
HREF=3D"http://www.webveda.com">http://www.webveda.com</A></FONT>

<BR><FONT =
SIZE=3D2>----------------------------------------------------------------=
----</FONT>

<BR><FONT SIZE=3D2>IETF IPng Working Group Mailing List</FONT>

<BR><FONT SIZE=3D2>IPng Home =
Page:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://playground.sun.com/ipng">http://playground.sun.com/ipng</A=
></FONT>

<BR><FONT SIZE=3D2>FTP =
archive:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"ftp://playground.sun.com/pub/ipng">ftp://playground.sun.com/pub/i=
png</A></FONT>

<BR><FONT SIZE=3D2>Direct all administrative requests to =
majordomo@sunroof.eng.sun.com</FONT>

<BR><FONT =
SIZE=3D2>----------------------------------------------------------------=
----</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFFCDE.2B26C0C4--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 19:33:37 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e732VcA26306
	for ipng-dist; Wed, 2 Aug 2000 19:31:38 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e732VT626299
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 19:31:30 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA03831
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 19:31:28 -0700 (PDT)
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07113
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 20:31:23 -0600 (MDT)
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id LAA01720;
	Thu, 3 Aug 2000 11:31:11 +0900
To: itojun@iijlab.net
Cc: ipng@sunroof.eng.sun.com, usagi@v6.linux.or.jp
Subject: Re: bind(2) ordering constraint
From: Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <200008021951.e72JpWW02883@ starfruit.itojun.org>
References: <200008021951.e72JpWW02883@ starfruit.itojun.org>
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000803113111X.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date: Thu, 03 Aug 2000 11:31:11 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 153
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

In article <200008021951.e72JpWW02883@ starfruit.itojun.org> (at Thu, 03 Aug 2000 04:51:32 +0900), Jun-ichiro itojun Hagino <itojun@iijlab.net> says:

> 	implementers, please run the attached program, and send the result to
> 	me, or to the list, with clear indication of
> 	- platform (like "NetBSD")
> 	- version (like "1.5_ALPHA")
> 	- comments, and some background info/reasoning for your behavior
> 	sample result is attached.

Platform: Linux
Version: 2.2.16
Comment: Debian GNU/Linux 2.2 (aka potato), tested on cerberus.
Tester: Hideaki YOSHIFUJI <yoshfuji@v6.linux.or.jp>

starting tests, socktype = SOCK_DGRAM
wild4 then wild4
	bind socket for 0.0.0.0/12345
	bind socket for 0.0.0.0/12345
	failed bind for 0.0.0.0/12345, Address already in use
wild4 then wild6
	bind socket for 0.0.0.0/12345
	bind socket for ::/12345
	failed bind for ::/12345, Address already in use
wild4 then loop4
	bind socket for 0.0.0.0/12345
	bind socket for 127.0.0.1/12345
	failed bind for 127.0.0.1/12345, Address already in use
wild4 then loop6
	bind socket for 0.0.0.0/12345
	bind socket for ::1/12345
	failed bind for ::1/12345, Address already in use
wild4 then one4
	bind socket for 0.0.0.0/12345
	bind socket for 0.0.0.1/12345
	failed bind for 0.0.0.1/12345, Address already in use
wild4 then map4
	bind socket for 0.0.0.0/12345
	bind socket for ::ffff:127.0.0.1/12345
	failed bind for ::ffff:127.0.0.1/12345, Address already in use
wild6 then wild4
	bind socket for ::/12345
	bind socket for 0.0.0.0/12345
	failed bind for 0.0.0.0/12345, Address already in use
wild6 then wild6
	bind socket for ::/12345
	bind socket for ::/12345
	failed bind for ::/12345, Address already in use
wild6 then loop4
	bind socket for ::/12345
	bind socket for 127.0.0.1/12345
	failed bind for 127.0.0.1/12345, Address already in use
wild6 then loop6
	bind socket for ::/12345
	bind socket for ::1/12345
	failed bind for ::1/12345, Address already in use
wild6 then one4
	bind socket for ::/12345
	bind socket for 0.0.0.1/12345
	failed bind for 0.0.0.1/12345, Address already in use
wild6 then map4
	bind socket for ::/12345
	bind socket for ::ffff:127.0.0.1/12345
	failed bind for ::ffff:127.0.0.1/12345, Address already in use
loop4 then wild4
	bind socket for 127.0.0.1/12345
	bind socket for 0.0.0.0/12345
	failed bind for 0.0.0.0/12345, Address already in use
loop4 then wild6
	bind socket for 127.0.0.1/12345
	bind socket for ::/12345
	failed bind for ::/12345, Address already in use
loop4 then loop4
	bind socket for 127.0.0.1/12345
	bind socket for 127.0.0.1/12345
	failed bind for 127.0.0.1/12345, Address already in use
loop4 then loop6
	bind socket for 127.0.0.1/12345
	bind socket for ::1/12345
loop4 then one4
	bind socket for 127.0.0.1/12345
	bind socket for 0.0.0.1/12345
loop4 then map4
	bind socket for 127.0.0.1/12345
	bind socket for ::ffff:127.0.0.1/12345
loop6 then wild4
	bind socket for ::1/12345
	bind socket for 0.0.0.0/12345
	failed bind for 0.0.0.0/12345, Address already in use
loop6 then wild6
	bind socket for ::1/12345
	bind socket for ::/12345
	failed bind for ::/12345, Address already in use
loop6 then loop4
	bind socket for ::1/12345
	bind socket for 127.0.0.1/12345
loop6 then loop6
	bind socket for ::1/12345
	bind socket for ::1/12345
	failed bind for ::1/12345, Address already in use
loop6 then one4
	bind socket for ::1/12345
	bind socket for 0.0.0.1/12345
loop6 then map4
	bind socket for ::1/12345
	bind socket for ::ffff:127.0.0.1/12345
one4 then wild4
	bind socket for 0.0.0.1/12345
	bind socket for 0.0.0.0/12345
	failed bind for 0.0.0.0/12345, Address already in use
one4 then wild6
	bind socket for 0.0.0.1/12345
	bind socket for ::/12345
	failed bind for ::/12345, Address already in use
one4 then loop4
	bind socket for 0.0.0.1/12345
	bind socket for 127.0.0.1/12345
one4 then loop6
	bind socket for 0.0.0.1/12345
	bind socket for ::1/12345
one4 then one4
	bind socket for 0.0.0.1/12345
	bind socket for 0.0.0.1/12345
	failed bind for 0.0.0.1/12345, Address already in use
one4 then map4
	bind socket for 0.0.0.1/12345
	bind socket for ::ffff:127.0.0.1/12345
map4 then wild4
	bind socket for ::ffff:127.0.0.1/12345
	bind socket for 0.0.0.0/12345
	failed bind for 0.0.0.0/12345, Address already in use
map4 then wild6
	bind socket for ::ffff:127.0.0.1/12345
	bind socket for ::/12345
	failed bind for ::/12345, Address already in use
map4 then loop4
	bind socket for ::ffff:127.0.0.1/12345
	bind socket for 127.0.0.1/12345
	failed bind for 127.0.0.1/12345, Address already in use
map4 then loop6
	bind socket for ::ffff:127.0.0.1/12345
	bind socket for ::1/12345
map4 then one4
	bind socket for ::ffff:127.0.0.1/12345
	bind socket for 0.0.0.1/12345
map4 then map4
	bind socket for ::ffff:127.0.0.1/12345
	bind socket for ::ffff:127.0.0.1/12345
	failed bind for ::ffff:127.0.0.1/12345, Address already in use

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  2 22:11:11 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7357m726449
	for ipng-dist; Wed, 2 Aug 2000 22:07:48 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged))
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7357V626442
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 22:07:32 -0700 (PDT)
Received: from jurassic.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7357OH280194;
	Wed, 2 Aug 2000 22:07:26 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Message-Id: <200008030507.e7357OH280194@jurassic.eng.sun.com>
Date: Wed, 2 Aug 2000 22:07:22 -0700
To: "Jun-ichiro itojun Hagino" <itojun@iijlab.net>, <ipng@sunroof.eng.sun.com>
Subject: Re: bind(2) ordering constraint
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


platform: Solaris
Version: Solaris 8

We the IPv4 and IPv6 port number spaces are separate. This facilitates certain upper layer protocols
like RPC that only have a notion of different transports. Thus RPC views e.g. UDP/IPv4 as a
different "transport" than UDP/IPv6.

starting tests, socktype = SOCK_DGRAM
wild4 then wild4
	bind socket for 0.0.0.0/9876
	bind socket for 0.0.0.0/9876
	failed bind for 0.0.0.0/9876, Address already in use
wild4 then wild6
	bind socket for 0.0.0.0/9876
	bind socket for ::/9876
wild4 then loop4
	bind socket for 0.0.0.0/9876
	bind socket for 127.0.0.1/9876
	failed bind for 127.0.0.1/9876, Address already in use
wild4 then loop6
	bind socket for 0.0.0.0/9876
	bind socket for ::1/9876
wild4 then one4
	bind socket for 0.0.0.0/9876
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
wild4 then map4
	bind socket for 0.0.0.0/9876
	bind socket for 127.0.0.1/9876
	failed bind for 127.0.0.1/9876, Address already in use
wild6 then wild4
	bind socket for ::/9876
	bind socket for 0.0.0.0/9876
wild6 then wild6
	bind socket for ::/9876
	bind socket for ::/9876
	failed bind for ::/9876, Address already in use
wild6 then loop4
	bind socket for ::/9876
	bind socket for 127.0.0.1/9876
wild6 then loop6
	bind socket for ::/9876
	bind socket for ::1/9876
	failed bind for ::1/9876, Address already in use
wild6 then one4
	bind socket for ::/9876
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
wild6 then map4
	bind socket for ::/9876
	bind socket for 127.0.0.1/9876
loop4 then wild4
	bind socket for 127.0.0.1/9876
	bind socket for 0.0.0.0/9876
	failed bind for 0.0.0.0/9876, Address already in use
loop4 then wild6
	bind socket for 127.0.0.1/9876
	bind socket for ::/9876
loop4 then loop4
	bind socket for 127.0.0.1/9876
	bind socket for 127.0.0.1/9876
	failed bind for 127.0.0.1/9876, Address already in use
loop4 then loop6
	bind socket for 127.0.0.1/9876
	bind socket for ::1/9876
loop4 then one4
	bind socket for 127.0.0.1/9876
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
loop4 then map4
	bind socket for 127.0.0.1/9876
	bind socket for 127.0.0.1/9876
	failed bind for 127.0.0.1/9876, Address already in use
loop6 then wild4
	bind socket for ::1/9876
	bind socket for 0.0.0.0/9876
loop6 then wild6
	bind socket for ::1/9876
	bind socket for ::/9876
	failed bind for ::/9876, Address already in use
loop6 then loop4
	bind socket for ::1/9876
	bind socket for 127.0.0.1/9876
loop6 then loop6
	bind socket for ::1/9876
	bind socket for ::1/9876
	failed bind for ::1/9876, Address already in use
loop6 then one4
	bind socket for ::1/9876
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
loop6 then map4
	bind socket for ::1/9876
	bind socket for 127.0.0.1/9876
one4 then wild4
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
one4 then wild6
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
one4 then loop4
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
one4 then loop6
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
one4 then one4
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
one4 then map4
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
map4 then wild4
	bind socket for 127.0.0.1/9876
	bind socket for 0.0.0.0/9876
	failed bind for 0.0.0.0/9876, Address already in use
map4 then wild6
	bind socket for 127.0.0.1/9876
	bind socket for ::/9876
map4 then loop4
	bind socket for 127.0.0.1/9876
	bind socket for 127.0.0.1/9876
	failed bind for 127.0.0.1/9876, Address already in use
map4 then loop6
	bind socket for 127.0.0.1/9876
	bind socket for ::1/9876
map4 then one4
	bind socket for 127.0.0.1/9876
	bind socket for 0.0.0.1/9876
	failed bind for 0.0.0.1/9876, Cannot assign requested address
map4 then map4
	bind socket for 127.0.0.1/9876
	bind socket for 127.0.0.1/9876
	failed bind for 127.0.0.1/9876, Address already in use

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

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 03:00:47 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e739xN526611
	for ipng-dist; Thu, 3 Aug 2000 02:59:23 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e739xD626604
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 02:59:13 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA02355
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 02:59:12 -0700 (PDT)
Received: from fsnt.future.futusoft.com ([203.197.140.35])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01244
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 02:59:09 -0700 (PDT)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futusoft.com
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0000867159@fsnt.future.futusoft.com>;
 Thu, 03 Aug 2000 15:41:23 +0530
Received: from muralia ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id PAA11078; Thu, 3 Aug 2000 15:16:40 +0530
Received: by localhost with Microsoft MAPI; Thu, 3 Aug 2000 15:20:34 +0530
Message-Id: <01BFFD5E.5E6FC680.muralia@future.futsoft.com>
From: Murali Krishna Ch <muralia@future.futsoft.com>
Reply-To: "muralia@future.futsoft.com" <muralia@future.futsoft.com>
To: "'Dave Thaler'" <dthaler@Exchange.Microsoft.com>,
   "ipng@webveda.com"
	 <ipng@webveda.com>,
   "ipng@sunroof.eng.sun.com"
	 <ipng@sunroof.eng.sun.com>
Subject: RE: IPv6 -over-IPv4 tunnel.
Date: Thu, 3 Aug 2000 15:20:33 +0530
Organization: Future Software
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


For IPv6 configured tunneling, this approach is clear.
But for Automatic Tunneling, I have a point here:
How does IPv6 differantiate between Automatic and configured tunnlling?
For Automatic Tunnelling the Destination v4 Address is fetched from the IPv4-compatibl-ipv6
address and in this case, there is no meaning of configuring the tunnel end points.
The point boils down to - how to identify rcving/xmitting interface index for Automatic Tunneling.

murali.


-----Original Message-----
From:	Dave Thaler [SMTP:dthaler@Exchange.Microsoft.com]
Sent:	Thursday, August 03, 2000 5:33 AM
To:	ipng@webveda.com; ipng@sunroof.eng.sun.com
Subject:	RE: IPv6 -over-IPv4 tunnel.

Yes, that was one of the intents of RFC 2667.

-Dave

-----Original Message-----
From: shankar [mailto:ipng@webveda.com]
Sent: Wednesday, August 02, 2000 8:29 AM
To: ipng@sunroof.eng.sun.com
Subject: IPv6 -over-IPv4 tunnel.


Hi folks,

cant we treat the IPv4 layer incase of IPv6/IPv4 nodes as a 
tunnel interface, with the local, remote IPv4 addresses as the 
tunnel configurations i.e. can we apply the new tunnel mib 2667
to this concept of tunneling. 

here a tunnel interface will be created, and the IPv6 routing table will
have
the IPv4 encap also as a interface. 

does that sound ok ?

tia
shankar
-------------------------------------------------
Make webveda your permanent address like i have.
Get 15 MB Free space only at http://www.webveda.com
--------------------------------------------------------------------
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
--------------------------------------------------------------------
 << File: ATT00005.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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 06:49:38 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73Dm2E26692
	for ipng-dist; Thu, 3 Aug 2000 06:48:02 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73Dls626685
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 06:47:54 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA07262
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 06:47:55 -0700 (PDT)
Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27444
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 07:47:53 -0600 (MDT)
Received: by alfa.itea.ntnu.no id PAA0000027124; Thu, 3 Aug 2000 15:47:40 +0200 (MET DST)
From: Stig Venås <venaas@alfa.itea.ntnu.no>
Date: Thu, 3 Aug 2000 15:47:40 +0200
To: Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, usagi@v6.linux.or.jp
Subject: Re: bind(2) ordering constraint
Message-ID: <20000803154740.A25289@itea.ntnu.no>
References: <200008021951.e72JpWW02883@ <200008021951.e72JpWW02883@ starfruit.itojun.org> <20000803113111X.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000803113111X.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>; from yoshfuji@ecei.tohoku.ac.jp on Thu, Aug 03, 2000 at 11:31:11AM +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is about what I expected, what I didn't like though was:

On Thu, Aug 03, 2000 at 11:31:11AM +0900, Hideaki YOSHIFUJI wrote:
> Platform: Linux
> Version: 2.2.16
> Comment: Debian GNU/Linux 2.2 (aka potato), tested on cerberus.
> Tester: Hideaki YOSHIFUJI <yoshfuji@v6.linux.or.jp>
> 
> starting tests, socktype = SOCK_DGRAM
> loop4 then map4
> 	bind socket for 127.0.0.1/12345
> 	bind socket for ::ffff:127.0.0.1/12345
> map4 then loop4
> 	bind socket for ::ffff:127.0.0.1/12345
> 	bind socket for 127.0.0.1/12345
> 	failed bind for 127.0.0.1/12345, Address already in use

I think the first one should fail as well. Anyone disagree?

Stig

-- 
Stig Venaas
UNINETT
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 07:17:11 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73EEcu26802
	for ipng-dist; Thu, 3 Aug 2000 07:14:38 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73EET626795
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 07:14:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA22138
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 07:14:30 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14938
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 08:14:24 -0600 (MDT)
Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA00962;
	Thu, 3 Aug 2000 22:59:42 +0900 (JST)
Date: Thu, 03 Aug 2000 23:09:44 +0900
Message-ID: <y7vr986a11z.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: crawdad@fnal.gov
Cc: ipng@sunroof.eng.sun.com
Subject: a tiny comment for draft-ietf-ipngwg-icmp-name-lookups-06.txt
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 15
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

the latest draft of icmp name lookup says as follows in Section 4
(page 5):

    Next, if Qtype is unknown to the Responder, it must return a NI
    Reply with ICMPv6 Type = 2 and no Reply Data.  The Responder should
               ^^^^^^^^^^^
    rate-limit such replies as it would ICMPv6 error replies [2463,
    2.4(f)].

I think "ICMPv6 Type" in the text should be "ICMPv6 Code".

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 08:35:03 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73FXRC26866
	for ipng-dist; Thu, 3 Aug 2000 08:33:27 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73FXI626859
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 08:33:18 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA04366
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 08:33:18 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA18258
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 08:33:17 -0700 (PDT)
Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 03 Aug 2000 08:17:26 -0700 (Pacific Daylight Time)
Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023);
	 Thu, 3 Aug 2000 08:26:37 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.4415.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01BFFD5E.59D168F4"
Subject: RE: bind(2) ordering constraint
Date: Thu, 3 Aug 2000 08:20:26 -0700
Message-ID: <19398D273324D3118A2B0008C7E9A5690C6F7B0C@SIT.platinum.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: bind(2) ordering constraint
Thread-Index: Ab/8vKHRzbqKa8DKRiavvXol0KOVMAAoOEZw
From: "Dave Thaler" <dthaler@Exchange.Microsoft.com>
To: "Jun-ichiro itojun Hagino" <itojun@iijlab.net>, <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 03 Aug 2000 15:26:37.0889 (UTC) FILETIME=[372A1B10:01BFFD5F]
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFFD5E.59D168F4
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Platform: Windows
Version: 2000
Comment: Output is identical to Itojun's netbsd output, except in
         two cases where multiple error codes apply and Windows
         chooses to generate a different one.

starting tests, socktype =3D SOCK_DGRAM
wild4 then wild4
	bind socket for 0.0.0.0/9999
	bind socket for 0.0.0.0/9999
	failed bind for 0.0.0.0/9999, Address already in use
wild4 then wild6
	bind socket for 0.0.0.0/9999
	bind socket for ::/9999
wild4 then loop4
	bind socket for 0.0.0.0/9999
	bind socket for 127.0.0.1/9999
	failed bind for 127.0.0.1/9999, Address already in use
wild4 then loop6
	bind socket for 0.0.0.0/9999
	bind socket for ::1/9999
wild4 then one4
	bind socket for 0.0.0.0/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Address already in use
wild4 then map4
	bind socket for 0.0.0.0/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
wild6 then wild4
	bind socket for ::/9999
	bind socket for 0.0.0.0/9999
wild6 then wild6
	bind socket for ::/9999
	bind socket for ::/9999
	failed bind for ::/9999, Address already in use
wild6 then loop4
	bind socket for ::/9999
	bind socket for 127.0.0.1/9999
wild6 then loop6
	bind socket for ::/9999
	bind socket for ::1/9999
	failed bind for ::1/9999, Address already in use
wild6 then one4
	bind socket for ::/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
wild6 then map4
	bind socket for ::/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Address already in use
loop4 then wild4
	bind socket for 127.0.0.1/9999
	bind socket for 0.0.0.0/9999
	failed bind for 0.0.0.0/9999, Address already in use
loop4 then wild6
	bind socket for 127.0.0.1/9999
	bind socket for ::/9999
loop4 then loop4
	bind socket for 127.0.0.1/9999
	bind socket for 127.0.0.1/9999
	failed bind for 127.0.0.1/9999, Address already in use
loop4 then loop6
	bind socket for 127.0.0.1/9999
	bind socket for ::1/9999
loop4 then one4
	bind socket for 127.0.0.1/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
loop4 then map4
	bind socket for 127.0.0.1/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
loop6 then wild4
	bind socket for ::1/9999
	bind socket for 0.0.0.0/9999
loop6 then wild6
	bind socket for ::1/9999
	bind socket for ::/9999
	failed bind for ::/9999, Address already in use
loop6 then loop4
	bind socket for ::1/9999
	bind socket for 127.0.0.1/9999
loop6 then loop6
	bind socket for ::1/9999
	bind socket for ::1/9999
	failed bind for ::1/9999, Address already in use
loop6 then one4
	bind socket for ::1/9999
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
loop6 then map4
	bind socket for ::1/9999
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
one4 then wild4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then wild6
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then loop4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then loop6
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then one4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
one4 then map4
	bind socket for 0.0.0.1/9999
	failed bind for 0.0.0.1/9999, Can't assign requested address
map4 then wild4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
map4 then wild6
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
map4 then loop4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
map4 then loop6
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
map4 then one4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address
map4 then map4
	bind socket for ::ffff:127.0.0.1/9999
	failed bind for ::ffff:127.0.0.1/9999, Can't assign requested
address

------_=_NextPart_001_01BFFD5E.59D168F4
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4415.0">
<TITLE>RE: bind(2) ordering constraint</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Platform: Windows</FONT>

<BR><FONT SIZE=3D2>Version: 2000</FONT>

<BR><FONT SIZE=3D2>Comment: Output is identical to Itojun's netbsd =
output, except in</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; two =
cases where multiple error codes apply and Windows</FONT>

<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
chooses to generate a different one.</FONT>
</P>

<P><FONT SIZE=3D2>starting tests, socktype =3D SOCK_DGRAM</FONT>

<BR><FONT SIZE=3D2>wild4 then wild4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.0/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>wild4 then wild6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR><FONT SIZE=3D2>wild4 then loop4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 127.0.0.1/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>wild4 then loop6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR><FONT SIZE=3D2>wild4 then one4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>wild4 then map4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>wild6 then wild4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR><FONT SIZE=3D2>wild6 then wild6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>wild6 then loop4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR><FONT SIZE=3D2>wild6 then loop6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::1/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>wild6 then one4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>wild6 then map4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>loop4 then wild4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.0/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>loop4 then wild6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR><FONT SIZE=3D2>loop4 then loop4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 127.0.0.1/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>loop4 then loop6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR><FONT SIZE=3D2>loop4 then one4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>loop4 then map4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>loop6 then wild4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.0/9999</FONT>

<BR><FONT SIZE=3D2>loop6 then wild6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>loop6 then loop4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 127.0.0.1/9999</FONT>

<BR><FONT SIZE=3D2>loop6 then loop6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::1/9999, Address already in use</FONT>

<BR><FONT SIZE=3D2>loop6 then one4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>loop6 then map4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>one4 then wild4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>one4 then wild6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>one4 then loop4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>one4 then loop6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>one4 then one4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>one4 then map4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for 0.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for 0.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>map4 then wild4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>map4 then wild6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>map4 then loop4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>map4 then loop6</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>map4 then one4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>

<BR><FONT SIZE=3D2>map4 then map4</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>bind =
socket for ::ffff:127.0.0.1/9999</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>failed =
bind for ::ffff:127.0.0.1/9999, Can't assign requested address</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFFD5E.59D168F4--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 09:01:49 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73G0Jk26928
	for ipng-dist; Thu, 3 Aug 2000 09:00:19 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73G0A626921
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 09:00:10 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA09908
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 09:00:10 -0700 (PDT)
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05456
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 10:00:06 -0600 (MDT)
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id AAA05652;
	Fri, 4 Aug 2000 00:59:57 +0900
To: venaas@alfa.itea.ntnu.no
Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com, usagi@v6.linux.or.jp
Subject: Re: bind(2) ordering constraint
From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
 <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <20000803154740.A25289@itea.ntnu.no>
References: <200008021951.e72JpWW02883@ <200008021951.e72JpWW02883@
 starfruit.itojun.org>
	<20000803113111X.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
	<20000803154740.A25289@itea.ntnu.no>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000804005957U.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date: Fri, 04 Aug 2000 00:59:57 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 28
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

In article <20000803154740.A25289@itea.ntnu.no> (at Thu, 3 Aug 2000 15:47:40 +0200), Stig Venås <venaas@alfa.itea.ntnu.no> says:

> This is about what I expected, what I didn't like though was:
> 
> On Thu, Aug 03, 2000 at 11:31:11AM +0900, Hideaki YOSHIFUJI wrote:
> > Platform: Linux
> > Version: 2.2.16
> > Comment: Debian GNU/Linux 2.2 (aka potato), tested on cerberus.
> > Tester: Hideaki YOSHIFUJI <yoshfuji@v6.linux.or.jp>
> > 
> > starting tests, socktype = SOCK_DGRAM
> > loop4 then map4
> > 	bind socket for 127.0.0.1/12345
> > 	bind socket for ::ffff:127.0.0.1/12345
> > map4 then loop4
> > 	bind socket for ::ffff:127.0.0.1/12345
> > 	bind socket for 127.0.0.1/12345
> > 	failed bind for 127.0.0.1/12345, Address already in use
> 
> I think the first one should fail as well. Anyone disagree?

This seems a bug in bind checking code (ipv4->::ffff.ipv4 case)).
I'm trying to fix this.

-- 
Hideaki YOSHIFUJI <yoshfuji@ecei.tohoku.ac.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 09:19:42 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73GIGV26964
	for ipng-dist; Thu, 3 Aug 2000 09:18:16 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73GI5626957
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 09:18:05 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA02241
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 09:18:06 -0700 (PDT)
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21312
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 09:18:02 -0700 (PDT)
Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1])
	by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA09582;
	Fri, 4 Aug 2000 01:17:56 +0900 (JST)
To: "Dave Thaler" <dthaler@Exchange.Microsoft.com>
cc: ipng@sunroof.eng.sun.com
In-reply-to: dthaler's message of Thu, 03 Aug 2000 08:20:26 MST.
      <19398D273324D3118A2B0008C7E9A5690C6F7B0C@SIT.platinum.corp.microsoft.com>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: bind(2) ordering constraint
From: itojun@iijlab.net
Date: Fri, 04 Aug 2000 01:17:56 +0900
Message-ID: <9580.965319476@coconut.itojun.org>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>Platform: Windows
>Version: 2000
>Comment: Output is identical to Itojun's netbsd output, except in
>         two cases where multiple error codes apply and Windows
>         chooses to generate a different one.
>
>wild6 then wild4
>	bind socket for ::/9999
>	bind socket for 0.0.0.0/9999

	this one contradicts from what you've told me yesterday...
	maybe i heard you wrong.

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 11:09:35 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73I7pR27114
	for ipng-dist; Thu, 3 Aug 2000 11:07:51 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73I7e627107
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 11:07:41 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA08577
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 11:07:40 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10724
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 11:07:37 -0700 (PDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA26676
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 13:07:36 -0500 (CDT)
Message-Id: <200008031807.NAA26676@gungnir.fnal.gov>
To: ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Comment on draft-ietf-ipngwg-addrconf-privacy-02
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26672.965326055.1@gungnir.fnal.gov>
Date: Thu, 03 Aug 2000 13:07:35 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Please remove the suggestion that DNS servers 'fabricate
"dummy" answers'!  The alternative, that nodes register
random names, is fine.
				Matt
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 12:44:11 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73JglW27274
	for ipng-dist; Thu, 3 Aug 2000 12:42:47 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73Jgd627267
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:42:39 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12421
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:42:38 -0700 (PDT)
Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15750
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:42:34 -0700 (PDT)
Received: by alfa.itea.ntnu.no id VAA0000031905; Thu, 3 Aug 2000 21:42:24 +0200 (MET DST)
From: Stig Venås <venaas@alfa.itea.ntnu.no>
Date: Thu, 3 Aug 2000 21:42:23 +0200
To: itojun@iijlab.net
Cc: Dave Thaler <dthaler@Exchange.Microsoft.com>, ipng@sunroof.eng.sun.com
Subject: Re: bind(2) ordering constraint
Message-ID: <20000803214223.A9415@itea.ntnu.no>
References: <19398D273324D3118A2B0008C7E9A5690C6F7B0C@SIT.platinum.corp.microsoft.com> <9580.965319476@coconut.itojun.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <9580.965319476@coconut.itojun.org>; from itojun@iijlab.net on Fri, Aug 04, 2000 at 01:17:56AM +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, Aug 04, 2000 at 01:17:56AM +0900, itojun@iijlab.net wrote:
> 
> >Platform: Windows
> >Version: 2000
> >Comment: Output is identical to Itojun's netbsd output, except in
> >         two cases where multiple error codes apply and Windows
> >         chooses to generate a different one.
> >
> >wild6 then wild4
> >	bind socket for ::/9999
> >	bind socket for 0.0.0.0/9999
> 
> 	this one contradicts from what you've told me yesterday...
> 	maybe i heard you wrong.

Yes, maybe I heard wrong too. Looks like Linux might be the odd one then.
Hope to see results from more implementations.

Stig
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 12:46:58 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73Jjxk27293
	for ipng-dist; Thu, 3 Aug 2000 12:45:59 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73Jjo627286
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:45:51 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13007
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:45:49 -0700 (PDT)
Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17615
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:45:48 -0700 (PDT)
Received: by alfa.itea.ntnu.no id VAA0000006705; Thu, 3 Aug 2000 21:45:45 +0200 (MET DST)
From: Stig Venås <venaas@alfa.itea.ntnu.no>
Date: Thu, 3 Aug 2000 21:45:45 +0200
To: Matt Crawford <crawdad@fnal.gov>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02
Message-ID: <20000803214545.B9415@itea.ntnu.no>
References: <200008031807.NAA26676@gungnir.fnal.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200008031807.NAA26676@gungnir.fnal.gov>; from crawdad@fnal.gov on Thu, Aug 03, 2000 at 01:07:35PM -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Thu, Aug 03, 2000 at 01:07:35PM -0500, Matt Crawford wrote:
> Please remove the suggestion that DNS servers 'fabricate
> "dummy" answers'!  The alternative, that nodes register
> random names, is fine.

How about registering a PTR record for the prefix, if some server can't
find a PTR record for the address, it could at least find out who owns
the prefix. The result would be just as meaningful as a zone full of
random names.

Stig
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 14:16:40 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e73LEGi27550
	for ipng-dist; Thu, 3 Aug 2000 14:14:16 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73LE8627543
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 14:14:08 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05385
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 14:14:09 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA14277
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 14:14:07 -0700 (PDT)
Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id GAA25166
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 06:14:05 +0900 (JST)
Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id GAA05590 for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 06:14:05 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id GAA00877 for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 06:14:04 +0900 (JST)
Date: Fri, 04 Aug 2000 06:13:47 +0900 (JST)
Message-Id: <20000804.061347.74669516.kazu@Mew.org>
To: ipng@sunroof.eng.sun.com
Subject: ENDS0
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
 <kazu@iijlab.net>
X-Mailer: Mew version 1.95b51 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Report on ENDS0 stuff:

My proposal is to mandate EDNS0 for IPv6 transport. That is, DNS
servers/resolvers MUST use EDNS0 if DNS querys/answers are carried
over IPv6.

There is another proposal from DNSEXT wg, described in
draft-ietf-dnsext-message-size-00.txt. It is to mandate EDNS0 for A6.
That is, DNS servers/resolvers MUST use EDNS0 if they support A6.

In this morning, at the session of DNSEXT, Olafur Gudmundsson, one of
co-chairs of the wg and the author of message-size, made presentation
on message-size. I explained about my proposal after him.

My proposal is DNS-transport oriented while Olafur's one is
DNS-contents oriented. In other words, my proposal is IPv6 specific as
Olafur's one is DNS specific. Impression is that we can pick up both
proposals since they are not contradictional.

Olafur suggested me that my proposal be included in "IPv6 Host
Requirements", on which Marc Blanchet is working. There were no strong
objections araised against this from those who were in the DNSEXT
session.

If there are no objections from IPNG wg, I will help Marc to get the
draft out.

P.S.

The minimum size of resolver's buffer is defined 1280 by both ENDS0
and message-size. This means that UDP payload size can be 1280, so
DNS/IPv6 would be fragmented at servers.

Some of us believe that we need to change 1280 to a smaller
value. Discussions are going on at the DNSEXT ml (namedroppers). If
you are interested in this topic, please subscribe to the list.

--Kazu
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 20:15:11 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e743DmF27755
	for ipng-dist; Thu, 3 Aug 2000 20:13:48 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e743De627748
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:13:40 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA01973
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:13:40 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26736
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 21:13:39 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA28675
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:13:39 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id UAA23060
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:13:36 -0700
X-Virus-Scanned:  Thu, 3 Aug 2000 20:13:36 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from maxdialin10.iprg.nokia.com (205.226.20.240, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd7iPlg2; Thu, 03 Aug 2000 20:13:32 PDT
Message-Id: <4.3.2.7.2.20000803201118.0246a608@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Aug 2000 20:12:59 -0700
To: ipng@sunroof.eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: W.G. Last Call on "Privacy Extensions for Stateless Address
  Autoconfiguration in IPv6s"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

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

         Title           : Privacy Extensions for Stateless Address
                           Autoconfiguration in IPv6
         Author(s)       : T. Narten, R. Draves
         Filename        : draft-ietf-ipngwg-addrconf-privacy-02.txt
         Pages           : 16
         Date            : 21-Jul-00

Please send substantive comments to the ipng mailing list, and minor
editorial comments to the authors.  This last call period will end two
week from today on August 17, 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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 20:16:09 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e743Eot27765
	for ipng-dist; Thu, 3 Aug 2000 20:14:50 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e743Ed627758
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:14:39 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA06609
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:14:38 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA27092
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 21:14:38 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA28704;
	Thu, 3 Aug 2000 20:14:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id UAA23227;
	Thu, 3 Aug 2000 20:14:35 -0700
X-Virus-Scanned:  Thu, 3 Aug 2000 20:14:35 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from maxdialin10.iprg.nokia.com (205.226.20.240, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd8tPLXt; Thu, 03 Aug 2000 20:14:32 PDT
Message-Id: <4.3.2.7.2.20000803201332.02437d98@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Aug 2000 20:14:25 -0700
To: ipng@sunroof.eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: reminder
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

If you gave a presentation at this week IPng sessions please send me your 
slides.

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 20:36:40 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e743ZNa27817
	for ipng-dist; Thu, 3 Aug 2000 20:35:23 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e743ZE627810
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:35:14 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA08208
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 20:35:13 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA05325
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 21:35:13 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA29677;
	Thu, 3 Aug 2000 20:35:13 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id UAA04927;
	Thu, 3 Aug 2000 20:35:11 -0700
X-Virus-Scanned:  Thu, 3 Aug 2000 20:35:11 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from maxdialin10.iprg.nokia.com (205.226.20.240, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdKriCPv; Thu, 03 Aug 2000 20:35:08 PDT
Message-Id: <4.3.2.7.2.20000803203333.02437d98@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 Aug 2000 20:34:59 -0700
To: ipng@sunroof.eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: W.G. Last Call on "IPv6 multihoming support at site exit
  routers"
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

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

         Title           : IPv6 multihoming support at site exit routers
         Author(s)       : J. Hagino
         Filename        : draft-ietf-ipngwg-ipv6-2260-00.txt
         Pages           : 9
         Date            : 26-Jun-00

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 August 17, 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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug  3 23:41:05 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e746d9i27905
	for ipng-dist; Thu, 3 Aug 2000 23:39:09 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e746d0627898
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 23:39:00 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA21157
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 23:39:01 -0700 (PDT)
Received: from mailweb8.rediffmail.com ([202.54.124.153])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA19479
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 00:38:55 -0600 (MDT)
Received: (qmail 26295 invoked by uid 510); 4 Aug 2000 06:37:43 -0000
Date: 4 Aug 2000 06:37:43 -0000
Message-ID: <20000804063743.26294.qmail@mailweb8.rediffmail.com>
MIME-Version: 1.0
To: "ipng@sunroof.eng.sun.com" <ipng@sunroof.eng.sun.com>
CC: "dhaskin@baynetworks.com" <dhaskin@baynetworks.com>
From: "Murali Krishna Ch" <chmurali@rediffmail.com>
Content-ID: <Fri_Aug__4_12_07_43_IST_2000_0@mailweb8.rediffmail.com>
Content-type: text/plain
Content-Description: 
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


In RFC 2465, the ipv6IfLowerLayer of IPv6IfEntry table
refers to an instance of either ifIndex or ipAdEntAddr.
Is this related to any tunneling of v6-over-v4?

The MIB for v6-over-v4 tunneling, is it defined in any RFC?

Since ipv6RouteTable is not-accessible and does contain
any RowStatus, does it mean that static/manual entries 
creation is not possible? If entries are to be created, how to proceed?

curious,
murali.



_________________________________________________
Get Your Free Email At, http://www.rediffmail.com

Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions



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

From owner-ipng@sunroof.eng.sun.com Fri Aug  4 07:47:53 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e74Ek2K28168
	for ipng-dist; Fri, 4 Aug 2000 07:46:02 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e74Ejo628161
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 07:45:50 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11885
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 07:45:50 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12677
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 08:45:48 -0600 (MDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA08677;
	Fri, 4 Aug 2000 09:45:35 -0500 (CDT)
Message-Id: <200008041445.JAA08677@gungnir.fnal.gov>
To: Stig =?UNKNOWN?Q?Ven=E5s?= <venaas@alfa.itea.ntnu.no>
Cc: ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02 
In-reply-to: Your message of Thu, 03 Aug 2000 21:45:45 +0200.
             <20000803214545.B9415@itea.ntnu.no> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8673.965400335.1@gungnir.fnal.gov>
Date: Fri, 04 Aug 2000 09:45:35 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> How about registering a PTR record for the prefix, if some server can't
> find a PTR record for the address, it could at least find out who owns
> the prefix. The result would be just as meaningful as a zone full of
> random names.

That would require the pesky servers (the ones demanding to
find your reverse mapping) be modified.  It's not likely to
happen.
				Matt
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug  4 07:48:20 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e74ElBV28177
	for ipng-dist; Fri, 4 Aug 2000 07:47:11 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e74Eku628170
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 07:46:56 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA12161
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 07:46:56 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13447;
	Fri, 4 Aug 2000 08:46:55 -0600 (MDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA08699;
	Fri, 4 Aug 2000 09:46:54 -0500 (CDT)
Message-Id: <200008041446.JAA08699@gungnir.fnal.gov>
To: Alain Durand <alain.durand@Sun.COM>
Cc: ipng@sunroof.eng.sun.com, crawdad@gungnir.fnal.gov
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02 
In-reply-to: Your message of Thu, 03 Aug 2000 13:01:09 PDT.
             <008f01bffd85$9239c340$a0844993@tycool.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8695.965400414.1@gungnir.fnal.gov>
Date: Fri, 04 Aug 2000 09:46:54 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> My suggestion was to use a wildcard PTR record for the /64 subnet.
>     - Alain.

That ought to do the trick.
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug  4 12:55:52 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e74Jol228334
	for ipng-dist; Fri, 4 Aug 2000 12:50:47 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e74Joc628327
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 12:50:38 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA16717
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 12:50:37 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA25531
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 13:50:36 -0600 (MDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 Aug 2000 12:40:20 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <QA2XKY2Y>; Fri, 4 Aug 2000 12:40:20 -0700
Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C322E@red-msg-24.redmond.corp.microsoft.com>
From: Christian Huitema <huitema@microsoft.com>
To: "'Stig Venås'" <venaas@alfa.itea.ntnu.no>,
   Matt Crawford
	 <crawdad@fnal.gov>
Cc: ipng@sunroof.eng.sun.com
Subject: RE: Comment on draft-ietf-ipngwg-addrconf-privacy-02
Date: Fri, 4 Aug 2000 12:41:19 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Matt,

The privacy requirements imply, if you use Dynamic DNS, that you create
names, addresses, and reverse mapping. For the direct records, this is
slightly different from the classic DDNS usage, in which you update the
value of the address record for a pre-existing name. In particular, if the
name already exists, the DNS can secure the transaction using pre-existing
info, such as the public key associated with the name. Not sure that
existing DNS servers will gladly let you create a large number of phony
names.

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug  4 15:09:17 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e74M7fx28430
	for ipng-dist; Fri, 4 Aug 2000 15:07:41 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e74M7W628423
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 15:07:32 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA19956
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 15:07:32 -0700 (PDT)
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16760
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 15:07:32 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id SAA23238; Fri, 4 Aug 2000 18:09:44 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5)
	id xma023229; Fri, 4 Aug 00 18:09:29 -0400
Received: from english.tislabs.com (clipper.gw.tislabs.com [10.33.1.2])
	by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id SAA10350;
	Fri, 4 Aug 2000 18:06:27 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000804162712.00bffe10@localhost>
X-Sender: ogud@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 04 Aug 2000 18:09:55 -0400
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu@iijlab.net>,
   ipng@sunroof.eng.sun.com
From: Olafur Gudmundsson <ogud@tislabs.com>
Subject: Re: ENDS0
In-Reply-To: <20000804.061347.74669516.kazu@Mew.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

At 05:13 PM 8/3/00, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote:
>Report on ENDS0 stuff:
>
>My proposal is to mandate EDNS0 for IPv6 transport. That is, DNS
>servers/resolvers MUST use EDNS0 if DNS querys/answers are carried
>over IPv6.
>
>There is another proposal from DNSEXT wg, described in
>draft-ietf-dnsext-message-size-00.txt. It is to mandate EDNS0 for A6.
>That is, DNS servers/resolvers MUST use EDNS0 if they support A6.
>
>In this morning, at the session of DNSEXT, Olafur Gudmundsson, one of
>co-chairs of the wg and the author of message-size, made presentation
>on message-size. I explained about my proposal after him.
>
>My proposal is DNS-transport oriented while Olafur's one is
>DNS-contents oriented. In other words, my proposal is IPv6 specific as
>Olafur's one is DNS specific. Impression is that we can pick up both
>proposals since they are not contradictional.
>
>Olafur suggested me that my proposal be included in "IPv6 Host
>Requirements", on which Marc Blanchet is working. There were no strong
>objections araised against this from those who were in the DNSEXT
>session.
>
>If there are no objections from IPNG wg, I will help Marc to get the
>draft out.


I discussed this with the IPng WG chairs yesterday, and
one of them suggested that the message-size draft actually mandate
EDNS0 for hosts with IPv6 installed. This is a stronger requirement
than I was willing to make, but the other chair suggested to
ask the working group if they thing this is a good idea.

And if they mind that DNSEXT starts dictating IPv6 host requirements.



>P.S.
>
>The minimum size of resolver's buffer is defined 1280 by both ENDS0
>and message-size. This means that UDP payload size can be 1280, so
>DNS/IPv6 would be fragmented at servers.
>
>Some of us believe that we need to change 1280 to a smaller
>value. Discussions are going on at the DNSEXT ml (namedroppers). If
>you are interested in this topic, please subscribe to the list.


Just for your information, 1280 was put in there hoping for input on
what is the LARGEST value we can get away and avoid fragmentation
by IPv6 most of the time.

DNSSEC is the main motivator for the draft, IPv6 is a beneficiary.

Discussions on what the value should take place on DNSEXT mailing list
namedroppers@ops.ietf.org

Discussions on if EDNS0 should be mandated for IPv6 capable hosts
should take place here on ipng mailing list.

         Olafur

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

From owner-ipng@sunroof.eng.sun.com Sat Aug  5 17:09:28 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7608B228778
	for ipng-dist; Sat, 5 Aug 2000 17:08:11 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76080628771
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:08:00 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA09253
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:07:59 -0700 (PDT)
Received: from roll.mentat.com ([192.88.122.129])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA06084
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:07:59 -0700 (PDT)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA25788;
	Sat, 5 Aug 2000 17:08:42 -0700 (PDT)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA19299;
	Sat, 5 Aug 2000 17:08:42 -0700 (PDT)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id RAA10794;
	Sat, 5 Aug 2000 17:12:49 -0700 (PDT)
Date: Sat, 5 Aug 2000 17:12:49 -0700 (PDT)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200008060012.RAA10794@feller.mentat.com>
To: ipng@sunroof.eng.sun.com, itojun@iijlab.net
Subject: Re: bind(2) ordering constraint
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk




Itojun,

	This is what our implementation does.  Not too surprisingly the
behavior below doesn't match what I said our implementation did.  It is
quite a bit more restrictive than I had remembered.

	Unlike Solaris and I guess Windows we don't have independent
port spaces for IPv6 and IPv4 although that seems to be the easiest way
to avoid messing up existing IPv4 binaries.


starting tests, socktype = SOCK_DGRAM
wild4 then wild4
	bind socket for 0.0.0.0/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
wild4 then wild6
	bind socket for 0.0.0.0/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
wild4 then loop4
	bind socket for 0.0.0.0/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
wild4 then loop6
	bind socket for 0.0.0.0/8888
	bind socket for ::1/8888
	failed bind for ::1/8888, Address already in use
wild4 then one4
	bind socket for 0.0.0.0/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Address already in use
wild4 then map4
	bind socket for 0.0.0.0/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
wild6 then wild4
	bind socket for ::/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
wild6 then wild6
	bind socket for ::/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
wild6 then loop4
	bind socket for ::/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
wild6 then loop6
	bind socket for ::/8888
	bind socket for ::1/8888
	failed bind for ::1/8888, Address already in use
wild6 then one4
	bind socket for ::/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Address already in use
wild6 then map4
	bind socket for ::/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
loop4 then wild4
	bind socket for 127.0.0.1/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
loop4 then wild6
	bind socket for 127.0.0.1/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
loop4 then loop4
	bind socket for 127.0.0.1/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
loop4 then loop6
	bind socket for 127.0.0.1/8888
	bind socket for ::1/8888
loop4 then one4
	bind socket for 127.0.0.1/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
loop4 then map4
	bind socket for 127.0.0.1/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
loop6 then wild4
	bind socket for ::1/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
loop6 then wild6
	bind socket for ::1/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
loop6 then loop4
	bind socket for ::1/8888
	bind socket for 127.0.0.1/8888
loop6 then loop6
	bind socket for ::1/8888
	bind socket for ::1/8888
	failed bind for ::1/8888, Address already in use
loop6 then one4
	bind socket for ::1/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
loop6 then map4
	bind socket for ::1/8888
	bind socket for ::ffff:127.0.0.1/8888
one4 then wild4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
one4 then wild6
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
one4 then loop4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
one4 then loop6
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
one4 then one4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
one4 then map4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
map4 then wild4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
map4 then wild6
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
map4 then loop4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
map4 then loop6
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for ::1/8888
map4 then one4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Cannot assign requested address
map4 then map4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use

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

From owner-ipng@sunroof.eng.sun.com Sat Aug  5 17:16:38 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e760Fbp28805
	for ipng-dist; Sat, 5 Aug 2000 17:15:37 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e760FH628798
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:15:18 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA22554
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:15:18 -0700 (PDT)
Received: from lychee.itojun.org (ny-ppp018.iij-us.net [216.98.99.18])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA07359
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:15:15 -0700 (PDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e760F0325038;
	Sun, 6 Aug 2000 09:15:00 +0900 (JST)
Message-Id: <200008060015.e760F0325038@itojun.org>
To: Tim Hartrick <tim@mentat.com>
cc: ipng@sunroof.eng.sun.com
In-reply-to: tim's message of Sat, 05 Aug 2000 17:12:49 MST.
      <200008060012.RAA10794@feller.mentat.com> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: bind(2) ordering constraint 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Sun, 06 Aug 2000 09:15:00 +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>	This is what our implementation does.  Not too surprisingly the
>behavior below doesn't match what I said our implementation did.  It is
>quite a bit more restrictive than I had remembered.

>wild4 then wild6
>	bind socket for 0.0.0.0/8888
>	bind socket for ::/8888
>	failed bind for ::/8888, Address already in use

>wild6 then wild4
>	bind socket for ::/8888
>	bind socket for 0.0.0.0/8888
>	failed bind for 0.0.0.0/8888, Address already in use

	thanks, doesn't the "wild4 then wild6" entry cause some problem
	for you?

	actually, if we have bind(2) ordering constraint in the kernel,
	the order of return value from getaddrinfo(3) has to be carefully
	designed - in your case, I bet you need to return AF_INET6 first on
	AI_PASSIVE getaddrinfo lookup.

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Aug  5 17:25:21 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e760Nt428835
	for ipng-dist; Sat, 5 Aug 2000 17:23:55 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e760Ni628828
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:23:45 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA07211
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:23:44 -0700 (PDT)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08841
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 17:23:44 -0700 (PDT)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA25835;
	Sat, 5 Aug 2000 17:23:55 -0700 (PDT)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA19599;
	Sat, 5 Aug 2000 17:23:56 -0700 (PDT)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id RAA10805;
	Sat, 5 Aug 2000 17:28:03 -0700 (PDT)
Date: Sat, 5 Aug 2000 17:28:03 -0700 (PDT)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200008060028.RAA10805@feller.mentat.com>
To: itojun@iijlab.net
Subject: Re: bind(2) ordering constraint
Cc: ipng@sunroof.eng.sun.com
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk





Itojun,

> 
> >	This is what our implementation does.  Not too surprisingly the
> >behavior below doesn't match what I said our implementation did.  It is
> >quite a bit more restrictive than I had remembered.
> 
> >wild4 then wild6
> >	bind socket for 0.0.0.0/8888
> >	bind socket for ::/8888
> >	failed bind for ::/8888, Address already in use
> 
> >wild6 then wild4
> >	bind socket for ::/8888
> >	bind socket for 0.0.0.0/8888
> >	failed bind for 0.0.0.0/8888, Address already in use
> 
> 	thanks, doesn't the "wild4 then wild6" entry cause some problem
> 	for you?
>

It could but to this point it hasn't caused problems for simple inetd
type applications like telnet and ftp.

In particular the errors above could be avoided by simply using SO_REUSEADDR
on the second socket before the second call to bind.

That is what thing that is missing from your test program.  SO_REUSEADDR
and SO_REUSEPORT settings.

I suspect that we will need to change our implementation to be more forgiving
regarding the above tests and probably others as well.

> 	actually, if we have bind(2) ordering constraint in the kernel,
> 	the order of return value from getaddrinfo(3) has to be carefully
> 	designed - in your case, I bet you need to return AF_INET6 first on
> 	AI_PASSIVE getaddrinfo lookup.
> 

I am not sure what you mean here exactly.  Since the above failures occur
regardless of order I don't see why it would make any difference in which
order the addresses were returned from getaddrinfo.

In this case I was running our stack on Linux and using the getaddrinfo
which comes with Redhat 6.1 (glibc 2.0.x).



tim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Aug  5 18:27:58 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e761QgW28877
	for ipng-dist; Sat, 5 Aug 2000 18:26:42 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e761QV628870
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 18:26:32 -0700 (PDT)
Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18])
	by jurassic.eng.sun.com (8.10.2+Sun/8.10.2) with SMTP id e761QVH387032;
	Sat, 5 Aug 2000 18:26:31 -0700 (PDT)
Date: Sat, 5 Aug 2000 18:26:16 -0700 (PDT)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Comments on draft-conta-extensions-ipv6-tunnel-00.txt
To: ipng@sunroof.eng.sun.com
Cc: nordmark@jurassic.eng.sun.com
Message-ID: <Roam.SIMC.2.0.6.965525176.23068.nordmark@jurassic>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Alex,

I really really don't see the need for what the draft calls "symmetric
bi-directional tunnels".

While such constructs might be used in the traffic engineering context
the TE context comes with a control protocol (MPLS) for setting up
the explicit paths and recovering from failure.
Getting MPLS to control IPv6-in-IPv6 tunnels would be a huge exercise
of very questionable value.

Thus my personal opinion is that the draft should only specify "regular"
bi-directional tunnels.

   Erik

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

From owner-ipng@sunroof.eng.sun.com Sat Aug  5 20:41:48 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e763eVh28934
	for ipng-dist; Sat, 5 Aug 2000 20:40:31 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e763eL628927
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 20:40:21 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA16281
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 20:40:19 -0700 (PDT)
Received: from lychee.itojun.org (ny-ppp010.iij-us.net [216.98.99.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12463
	for <ipng@sunroof.eng.sun.com>; Sat, 5 Aug 2000 20:40:18 -0700 (PDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e763e7325177;
	Sun, 6 Aug 2000 12:40:07 +0900 (JST)
Message-Id: <200008060340.e763e7325177@itojun.org>
To: Tim Hartrick <tim@mentat.com>
cc: ipng@sunroof.eng.sun.com
In-reply-to: tim's message of Sat, 05 Aug 2000 17:28:03 MST.
      <200008060028.RAA10805@feller.mentat.com> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: bind(2) ordering constraint 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Sun, 06 Aug 2000 12:40:07 +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>> 	actually, if we have bind(2) ordering constraint in the kernel,
>> 	the order of return value from getaddrinfo(3) has to be carefully
>> 	designed - in your case, I bet you need to return AF_INET6 first on
>> 	AI_PASSIVE getaddrinfo lookup.
>I am not sure what you mean here exactly.  Since the above failures occur
>regardless of order I don't see why it would make any difference in which
>order the addresses were returned from getaddrinfo.

	assuming that you do RFC2553-inbound,
	- if you bind(2) to AF_INET6 before AF_INET, (a) AF_INET bind fails,
	  but (b) you will accept both IPv4 and IPv6 traffic into AF_INET6
	  socket.
	- if you bind(2) to AF_INET before AF_INET6, (a) AF_INET6 bind fails,
	  and (b) you will accept IPv4 traffic only, into AF_INET socket.

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug  6 03:20:25 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e76AJ7Y29068
	for ipng-dist; Sun, 6 Aug 2000 03:19:07 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76AIu629061
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 03:18:57 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA13992
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 03:18:56 -0700 (PDT)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21743
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 03:18:54 -0700 (PDT)
Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21])
	by mail.lysator.liu.se (Postfix) with ESMTP
	id 42DC12409FFF; Sun,  6 Aug 2000 12:18:52 +0200 (MET DST)
Received: (from nisse@localhost)
	by sture.lysator.liu.se (8.9.0/8.8.7) id MAA13862;
	Sun, 6 Aug 2000 12:18:51 +0200 (MET DST)
To: Brian Zill <bzill@microsoft.com>
Cc: "'itojun@iijlab.net'" <itojun@iijlab.net>, ipng@sunroof.eng.sun.com
Subject: Re: New "IP Version 6 Addressing Architecture" draft
References: <2E3FA0558747934A8F753CC533A3F6DF011021@red-msg-24.redmond.corp.microsoft.com>
From: nisse@lysator.liu.se (Niels Möller)
Date: 06 Aug 2000 12:18:50 +0200
In-Reply-To: Brian Zill's message of "Fri, 21 Jul 2000 21:44:36 -0700"
Message-ID: <nnwvhur8tx.fsf@sture.lysator.liu.se>
Lines: 86
X-Mailer: Gnus v5.7/Emacs 20.7
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Brian Zill <bzill@microsoft.com> writes:

> What I'm saying is that I don't see why you'd ever need to guess. It
> shouldn't matter to the user-land program how the packet got there.
> The kernel should ensure that you get a v4-mapped packet with wire
> format of IPv6 if and only if it would have let you get the same
> packet with a wire format of IPv4.

I'll try to make up a scenario where it matters, and try to draw some
conclusions. 

Say I have a box with two interfaces, one IPv6 interface connected to
the dangerous internet, and an IPv4 interface connected to a local
IPv4 only trusted network.

The box is running a dual stack, and there is some server running on
it that listens on an IPv6 socket bound to the unspecified address,
which can accept both IPv6 connections and IPv4 connections. In the
latter case, getpeername returns a mapped address.

The server software uses some kind of source-address based access
control. As you have pointed out, the server has to recognize IPv4
mapped addresses and perform IPv4 access control [1] (this is not a
big issue, as the application uses only an IPv6 socket, so this is the
only place IPv4 addresses shows up).

The second is the rules... As the only IPv4 network the machine is
attached to is trusted, the user may have configured rules like "Any
IPv4 source is trusted". That's a bad assumption [2] to make, but I
think it is an easy mistake to make. (The assumption would be safe if
the stack dropped any packet that arrives on the wire with a mapped
source addresses).

Next, if the user is aware of this, he includes stricter rules, saying
that only IPv4 addresses on the local subnet are trusted. But packets
can still be faked by sending packets with mapped source addresses
from the internet; the application will believe that they originate
from the trusted local network. [3] Again, there is an easy mistake to
make: To assume that IPv4 packets can't be faked by addressing them to
an IPv6 interface.

These are three related but dfferent problems, that need to be
considered separately. Let's see what we can do:

1. For applications that use mapped addresses to deal with IPv4 peers,
   this is just natural. But for an application that listens on two
   sockets, one IPv4 (bound to the unspecified IPv4 address) and one
   IPv6 (bound to the unspecified IPv6), it's natural to expect that
   any IPv4 peer will connect to the IPv4 socket, not the IPv6 one.

   In this case, one would want to configure the IPv6 socket to never
   ever pass on a packet with a mapped source address, no matter if
   the mapped address appeared on the wire or was generated
   internally. (I seem to recall that there is some option to do that,
   on a by socket basis). Otherwise, the application has to reject
   mapped addresses. In anycase, this doesn't have much to with mapped
   addresses on the wire.

2. I think there are only two approaches: Either forbid mapped
   addresses on the wire, or teach users and developers that they must
   never make the assumtion above. I.e. teach them that it is possible
   to recieve packets that, from access control point of view *are*
   IPv4 packets, on an IPv6 only interface.

3. Here, the answer is probably some kind of ingress filtering. The
   stack should know which addresses belongs to the trusted network,
   and drop packets with addresses belonging to that network, unless
   they arrive the IPv4 interface attached directly to that network. I
   believe that this is particularly important for tcp, because there
   it is extremely inconvenient for the application to check the
   incoming interface for each individual packet. The 
   filtering should be applied equally to IPv4 packets and IPv6
   packets with mapped addresses.

   The goal of the filtering (like for ingress filtering in general, I
   think), is to make sure that applications can look at source
   addresses and make valid assumptions about where a packet arrived
   from.

   The other alternative is to listen on more sockets, one for each
   interface, but that is messier to setup, in particular if you have
   several addresses on each interface. (Perhaps attaching a link-id in
   the scope-id field when binding the sockets, as discussed in some
   other thread, may come in handy).

/Niels
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug  6 05:32:45 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e76CVUP29222
	for ipng-dist; Sun, 6 Aug 2000 05:31:30 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76CVK629215
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 05:31:21 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA28418
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 05:31:19 -0700 (PDT)
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA10879
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 05:31:19 -0700 (PDT)
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id VAA00848;
	Sun, 6 Aug 2000 21:30:57 +0900
To: itojun@iijlab.net
Cc: tim@mentat.com, ipng@sunroof.eng.sun.com
Subject: Re: bind(2) ordering constraint 
From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
 <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <200008060015.e760F0325038@itojun.org>
References: <200008060012.RAA10794@feller.mentat.com>
	<200008060015.e760F0325038@itojun.org>
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000806213056F.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date: Sun, 06 Aug 2000 21:30:56 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 14
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

In article <200008060015.e760F0325038@itojun.org> (at Sun, 06 Aug 2000 09:15:00 +0900), Jun-ichiro itojun Hagino <itojun@iijlab.net> says:

> 	actually, if we have bind(2) ordering constraint in the kernel,
> 	the order of return value from getaddrinfo(3) has to be carefully
> 	designed - in your case, I bet you need to return AF_INET6 first on
> 	AI_PASSIVE getaddrinfo lookup.

Yes, getaddrinfo() flagged AI_PASSIVE with PF_UNSPEC hints SHOULD return 
PF_INET6 before PF_INET.  glibc is ok at this point.

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug  6 06:55:06 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e76DnpS29265
	for ipng-dist; Sun, 6 Aug 2000 06:49:51 -0700 (PDT)
Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76Dnc629258
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 06:49:42 -0700 (PDT)
Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66])
	by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19309;
	Sun, 6 Aug 2000 09:49:38 -0400 (EDT)
Received: from thunk.east.sun.com (localhost [127.0.0.1])
	by thunk.east.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76DnCS110915;
	Sun, 6 Aug 2000 09:49:13 -0400 (EDT)
Message-Id: <200008061349.e76DnCS110915@thunk.east.sun.com>
From: Bill Sommerfeld <sommerfeld@east.sun.com>
To: nisse@lysator.liu.se (Niels M ller)
cc: Brian Zill <bzill@microsoft.com>,
   "'itojun@iijlab.net'" <itojun@iijlab.net>, ipng@sunroof.eng.sun.com
Subject: Re: New "IP Version 6 Addressing Architecture" draft 
In-reply-to: Your message of "06 Aug 2000 12:18:50 +0200."
             <nnwvhur8tx.fsf@sture.lysator.liu.se> 
Reply-to: sommerfeld@east.sun.com
Date: Sun, 06 Aug 2000 09:49:12 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

   The other alternative is to listen on more sockets, one for each
   interface, but that is messier to setup, in particular if you have
   several addresses on each interface. (Perhaps attaching a link-id in
   the scope-id field when binding the sockets, as discussed in some
   other thread, may come in handy).

This gets especially messy when interfaces are renumbered/new prefixes
are advertised, or if interfaces can be dynamically added/deleted.

					- Bill
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug  6 08:19:23 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e76FHmv29337
	for ipng-dist; Sun, 6 Aug 2000 08:17:48 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76FHb629330
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 08:17:37 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03290
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 08:17:36 -0700 (PDT)
Received: from lychee.itojun.org (ny-ppp001.iij-us.net [216.98.99.1])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08058
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 08:17:35 -0700 (PDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e76FHP325598;
	Mon, 7 Aug 2000 00:17:25 +0900 (JST)
Message-Id: <200008061517.e76FHP325598@itojun.org>
To: Hideaki YOSHIFUJI (=?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?=)
  <yoshfuji@ecei.tohoku.ac.jp>
cc: tim@mentat.com, ipng@sunroof.eng.sun.com
In-reply-to: yoshfuji's message of Sun, 06 Aug 2000 21:30:56 JST.
      <20000806213056F.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: bind(2) ordering constraint 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Mon, 07 Aug 2000 00:17:25 +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>> 	the order of return value from getaddrinfo(3) has to be carefully
>> 	designed - in your case, I bet you need to return AF_INET6 first on
>> 	AI_PASSIVE getaddrinfo lookup.
>Yes, getaddrinfo() flagged AI_PASSIVE with PF_UNSPEC hints SHOULD return 
>PF_INET6 before PF_INET.  glibc is ok at this point.

	"getaddrinfo(3) should sort replies so that it respects bind(2)
	behavior".  for Tim's case and linux's case, due to bind(2) behavior,
	getaddrinfo(3) should return AF_INET6 entries first.

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug  6 11:00:19 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e76Hx0j29416
	for ipng-dist; Sun, 6 Aug 2000 10:59:00 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76Hwp629409
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 10:58:51 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA16346
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 10:58:50 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09637
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 10:58:45 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e76Hw7620353;
	Sun, 6 Aug 2000 19:58:08 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA22972;
	Sun, 6 Aug 2000 19:58:06 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA05574;
	Sun, 6 Aug 2000 19:59:44 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008061759.TAA05574@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
cc: ipng@sunroof.eng.sun.com
Subject: Re: bind(2) ordering constraint 
In-reply-to: Your message of Thu, 03 Aug 2000 04:51:32 +0900.
             <200008021951.e72JpWW02883@ starfruit.itojun.org> 
Date: Sun, 06 Aug 2000 19:59:44 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   	implementers, please run the attached program, and send the result to
   	me, or to the list, with clear indication of
   	- platform (like "NetBSD")

=> FreeBSD

   	- version (like "1.5_ALPHA")

=> 3.4 + INRIA IPv6 stack (20000503)

   	- comments, and some background info/reasoning for your behavior
   	sample result is attached.
   
=> IPv4 and IPv6 port spaces are shared. This was never a problem but
most daemons use of course SO_REUSEADDR option then I'd like to give
the result of this test with SO_REUSEADDR set (SO_REUSEPORT is for multicast
and gives infinite reuse).
 I should add some [gs]etsockopts dedicated to IPv6 applied to a socket
disable further IPv4 usage and this fact is used at least somewhere
(ie. the IPv4 disable setsockopt doesn't exist but is used :-).

Francis.Dupont@enst-bretagne.fr

starting tests, socktype = SOCK_DGRAM
wild4 then wild4
	bind socket for 0.0.0.0/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
wild4 then wild6
	bind socket for 0.0.0.0/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
wild4 then loop4
	bind socket for 0.0.0.0/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
wild4 then loop6
	bind socket for 0.0.0.0/8888
	bind socket for ::1/8888
wild4 then one4
	bind socket for 0.0.0.0/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
wild4 then map4
	bind socket for 0.0.0.0/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
wild6 then wild4
	bind socket for ::/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
wild6 then wild6
	bind socket for ::/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
wild6 then loop4
	bind socket for ::/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
wild6 then loop6
	bind socket for ::/8888
	bind socket for ::1/8888
	failed bind for ::1/8888, Address already in use
wild6 then one4
	bind socket for ::/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
wild6 then map4
	bind socket for ::/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
loop4 then wild4
	bind socket for 127.0.0.1/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
loop4 then wild6
	bind socket for 127.0.0.1/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
loop4 then loop4
	bind socket for 127.0.0.1/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
loop4 then loop6
	bind socket for 127.0.0.1/8888
	bind socket for ::1/8888
loop4 then one4
	bind socket for 127.0.0.1/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
loop4 then map4
	bind socket for 127.0.0.1/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
loop6 then wild4
	bind socket for ::1/8888
	bind socket for 0.0.0.0/8888
loop6 then wild6
	bind socket for ::1/8888
	bind socket for ::/8888
loop6 then loop4
	bind socket for ::1/8888
	bind socket for 127.0.0.1/8888
loop6 then loop6
	bind socket for ::1/8888
	bind socket for ::1/8888
	failed bind for ::1/8888, Address already in use
loop6 then one4
	bind socket for ::1/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
loop6 then map4
	bind socket for ::1/8888
	bind socket for ::ffff:127.0.0.1/8888
one4 then wild4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
one4 then wild6
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
one4 then loop4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
one4 then loop6
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
one4 then one4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
one4 then map4
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
map4 then wild4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for 0.0.0.0/8888
	failed bind for 0.0.0.0/8888, Address already in use
map4 then wild6
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for ::/8888
	failed bind for ::/8888, Address already in use
map4 then loop4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for 127.0.0.1/8888
	failed bind for 127.0.0.1/8888, Address already in use
map4 then loop6
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for ::1/8888
map4 then one4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for 0.0.0.1/8888
	failed bind for 0.0.0.1/8888, Can't assign requested address
map4 then map4
	bind socket for ::ffff:127.0.0.1/8888
	bind socket for ::ffff:127.0.0.1/8888
	failed bind for ::ffff:127.0.0.1/8888, Address already in use
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug  6 11:03:01 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e76I2BY29443
	for ipng-dist; Sun, 6 Aug 2000 11:02:12 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e76I23629436
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 11:02:03 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA16570
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 11:02:03 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10396
	for <ipng@sunroof.eng.sun.com>; Sun, 6 Aug 2000 11:02:01 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e76I1R651867;
	Sun, 6 Aug 2000 20:01:27 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA22989;
	Sun, 6 Aug 2000 20:01:27 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id UAA05603;
	Sun, 6 Aug 2000 20:03:04 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008061803.UAA05603@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
cc: ipng@sunroof.eng.sun.com
Subject: Re: bind(2) ordering constraint 
In-reply-to: Your message of Thu, 03 Aug 2000 04:51:32 +0900.
             <200008021951.e72JpWW02883@ starfruit.itojun.org> 
Date: Sun, 06 Aug 2000 20:03:04 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

NetBSD 1.4.1 with INRIA stack (20000503): same results than with FreeBSD!

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 05:01:03 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77BxOr29887
	for ipng-dist; Mon, 7 Aug 2000 04:59:24 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77BxF629880
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 04:59:15 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA10081
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 04:59:14 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA07425
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 04:59:12 -0700 (PDT)
Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA03389
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:59:11 +0900 (JST)
Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA25129 for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:59:11 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA28550 for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:59:11 +0900 (JST)
Date: Mon, 07 Aug 2000 20:58:59 +0900 (JST)
Message-Id: <20000807.205859.85324769.kazu@Mew.org>
To: ipng@sunroof.eng.sun.com
Subject: Re: ENDS0
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
 <kazu@iijlab.net>
In-Reply-To: <4.3.2.7.2.20000804162712.00bffe10@localhost>
References: <20000804.061347.74669516.kazu@Mew.org>
	<4.3.2.7.2.20000804162712.00bffe10@localhost>
X-Mailer: Mew version 1.95b51 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

From: Olafur Gudmundsson <ogud@tislabs.com>
Subject: Re: ENDS0

> I discussed this with the IPng WG chairs yesterday, and
> one of them suggested that the message-size draft actually mandate
> EDNS0 for hosts with IPv6 installed. This is a stronger requirement
> than I was willing to make, but the other chair suggested to
> ask the working group if they thing this is a good idea.

Just for clarification. Does this mean dropping my proposal? Or pick
up both and put them into a draft of IPv6 host requirement?

> Discussions on if EDNS0 should be mandated for IPv6 capable hosts
> should take place here on ipng mailing list.

OK.

I would like to propose as follows:

(1) DNS resolvers MUST implement EDNS0 if they support IPv6 transport
    or AAAA/A6. Such resolvers SHOULD specify 2048 (*1) bytes as
    buffer size to servers. (This requires larger IPv6 reassemble
    buffer than the minimum, ie 1500.)

# (*1) need to discuss an appropriate size

(2) DNS servers MUST implement EDNS if they support IPv6 transport or
    AAAA/A6. They MUST assume client's buffer size is 1024 (*2) if
    clients doesn't specify their buffer size by ENDS0.

# (*2) 1024 comes from the IPv6 minimum MTU, 1280 = 256 + 1024.

--Kazu
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 08:23:28 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77FLuZ00025
	for ipng-dist; Mon, 7 Aug 2000 08:21:56 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77FLl600018
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 08:21:47 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA02248
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 08:21:46 -0700 (PDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25142
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 08:21:38 -0700 (PDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id D70C32C7F; Mon,  7 Aug 2000 10:21:37 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP id 6841F140F
	for <ipng@sunroof.eng.sun.com>; Mon,  7 Aug 2000 10:21:37 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id LAA0000557116; Mon, 7 Aug 2000 11:21:33 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008071521.LAA0000557116@anw.zk3.dec.com>
To: ipng@sunroof.eng.sun.com
Subject: CHAIRS: Excellent Meeting
Date: Mon, 07 Aug 2000 11:21:33 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Steve and Bob,

Great job and a good meeting.  We got real work done.  So nice to
experience at an IETF meeting I wish others would follow your example as
Chairs.  It was not just a status update and the working group was able
to do real work.

regards and thanks,
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 09:21:31 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77GJr800063
	for ipng-dist; Mon, 7 Aug 2000 09:19:53 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77GJm600056
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 09:19:49 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA18052
	for ipng@sunroof.eng.sun.com; Mon, 7 Aug 2000 09:17:55 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e71LSW625330
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 14:28:32 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06178
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 14:28:33 -0700 (PDT)
Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22713
	for <ipng@sunroof.eng.sun.com>; Tue, 1 Aug 2000 14:28:29 -0700 (PDT)
Received: from wired-129-169.ietf.marconi.com ([147.73.129.169]:52492 "HELO kenawang" ident: "IDENT-NOT-QUERIED [port 52492]") by newquern.epilogue.com with SMTP id <654-175>; Tue, 1 Aug 2000 17:28:00 -0400
Message-Id: <4.2.2.20000801165220.0145bde0@localhost>
X-Sender: mrfpop@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
To: Richard Draves <richdr@microsoft.com>
From: Margaret Wasserman <mrw@epilogue.com>
Subject: RE: Scoped Addressing Architecture Routing Issue
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>
In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81025C71BF8@RED-MSG-50>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: 	Tue, 1 Aug 2000 17:28:00 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Rich,

>Your example also has the best route between H1 & H2 in site B, be to go
>through site A. This seems really unlikely to occur in actual practice. You
>seem to be implicitly assuming that the two sites are in a single IGP
>routing domain.

I am assuming that two sites _may_ be in the same routing domain, and
that problems could occur in that situation.  I don't believe that the
current IPv6 specifications assume that a single routing domain will 
always be a single site.  

My example packet could easily occur in response to a packet sent from
a host that doesn't have a site-local address (perhaps because it was
configured via DHCP?).  That host would need to use a global address to 
communicate with a site-local address, and the response would have
a site-local source and a global destination.  

The ICMP issue that you have described would also exist when using 
multiple "conceptual" routing tables in the case of a partitioned 
site.  For example:

==========================================================
SITEA
       Host1                      Host2
         |                          |
________|__.__._____  ____.______._|_____________
   Link1    |  |           |      |     Link2
            |  |          (down)  |        
            |  +-----R1----+      |
            |                     |
            |                     |
===========|=====================|=========================
SITEB      |                     |
            +--------R1-----------+

===========================================================

If a site-local packet (site-local destination and site-
local source) is send from Host1 to Host2, it would
probably be sent to the local router, R1.

R1 would then use the scoped addressing rules to forward the 
packet.  First, he would look at the destination address
to determine that he should look in the site-local table.
The site-local table would have no active route to Link2,
so he would send a Destination Unreachable/No Route 
To Destination message, _not_ a Scope Exceeded message.

In this case, it might actually be _useful_ for the sender 
to receive a Scope Exceeded message, because the sender might 
be able to switch to global communication.  The sender may 
have had both site-local and global addresses available, but
have chosen site-local communication.  But, he doesn't get the
Scope Exceeded message, so he can't act on it.

However, if a mixed scope packet is sent (global destination
and site-local source) from Host1 to Host2, R1 would look
in the global table, determine that a route exists to Link2
through R2, THEN discard the packet because of the site-local
source.  This would result in a Destination Unreachable/Scope
Exceeded message.  It seems unlikely, though, that Host1 would 
have sent a mixed-scope packet if he had a global address 
available for Host2, so the Scope Exceeded message is potentially 
_less_ useful in this situation.

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 09:28:49 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77GRiR00138
	for ipng-dist; Mon, 7 Aug 2000 09:27:44 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77GRe600131
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 09:27:40 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA18110
	for ipng@sunroof.eng.sun.com; Mon, 7 Aug 2000 09:25:46 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72Cno625676
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 05:49:50 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA27492
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 05:49:51 -0700 (PDT)
Received: from quern.epilogue.com (quern.epilogue.com [128.224.1.136])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05798
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 05:49:46 -0700 (PDT)
Received: from wired-129-169.ietf.marconi.com ([147.73.129.169]:9732 "HELO kenawang" ident: "IDENT-NOT-QUERIED [port 9732]") by newquern.epilogue.com with SMTP id <662-175>; Wed, 2 Aug 2000 08:49:37 -0400
Message-Id: <4.2.2.20000802073100.01beef00@localhost>
X-Sender: mrfpop@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 
To: IPng Working Group <ipng@sunroof.eng.sun.com>
From: Margaret Wasserman <mrw@epilogue.com>
Subject: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: 	Wed, 2 Aug 2000 08:49:37 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


In an attempt to simplify my earlier example, I oversimplified
it.  Here is a better diagram:

>The ICMP issue that you have described would also exist when using 
>multiple "conceptual" routing tables in the case of a partitioned 
>site. For example:



==========================================================
SITEA
             Host1                      Host2
               |                         |
       ______._|_________    ___.______._|_____________
       Link1 |                  |      |       Link2
             |                (down)   | 
             |                  |      |
             |+-----------------+      |
             ||                        |
============R1========================R3===================
SITEB       |                         |
             |                         |
        _____|_________________________|________________
                                                 Link3


===========================================================

Now, if Host1 sends a packet with site-local source and
site-local destination, it obviously won't reach Host2.
R1 will receive the packet, and will be unable to route 
the packet because there are no routes available in the 
conceptual site-local routing table for SITEA.  This
will result in an ICMP/No Route to Destination error.
The use of the conceptual routing table prevents R1 from
noticing that there is a global route to Link2, so the
potentially useful ICMP/Scope Exceeded error is not sent.

The user may see that some applications can reach Host2
and other can not, but no pertinent error message will
be displayed.  Also, "smart" applications do not receive
the information that addresses of a greater scope
could potentially reach the destination.

But, if Host1 sends a packet with site-local source and
global destination through the same path, the ICMP/Scope
Exceeded message will be returned.  

Is it is important to maintain the "Scope Exceeded" message
_only_ for packets where the destination scope is greater 
than the source scope?  Even if it means that we may discard
packets that could successfully reach the destination in
some cases (as in my first example)?

A mixed scope packet where the source is greater than the
destination is the _only_ time that a Scope Exceeded message
will be generated in the current architecture.  And, it
is one of the least useful times, since the mixed scope 
packet would not have been generated if the sender had the
option of using a matching scope address -- either because
a global address is not available, or because an upper layer
has chosen the addresses.  Also, the mixed scope packet
should be fairly obvious to a sophisticated network debugger,
even if it were returned in an ICMP/No Route to Destination
message.

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 09:52:04 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77GoRg00224
	for ipng-dist; Mon, 7 Aug 2000 09:50:27 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77GoN600217
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 09:50:23 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA18158
	for ipng@sunroof.eng.sun.com; Mon, 7 Aug 2000 09:48:29 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e72MIT626046
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 15:18:30 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA19772
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 15:18:30 -0700 (PDT)
From: Ptasillo@aol.com
Received: from imo-d10.mx.aol.com (imo-d10.mx.aol.com [205.188.157.42])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02817
	for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 2000 16:18:29 -0600 (MDT)
Message-Id: <200008022218.QAA02817@lukla.Sun.COM>
Received: from Ptasillo@aol.com
	by imo-d10.mx.aol.com (mail_out_v27.12.) id 1.f6.177e749 (15700);
	Wed, 2 Aug 2000 18:18:24 -0400 (EDT)
Received: from  web41.aolmail.aol.com (web41.aolmail.aol.com [205.188.161.2]) by air-id05.mx.aol.com (v75_b3.11) with ESMTP; Wed, 02 Aug 2000 18:18:24 -0400
Date: Wed, 02 Aug 2000 18:18:23 EDT
Subject: auto dns discovery
To: <ipng@sunroof.eng.sun.com>
Cc: <paul.tasillo@tivoli.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailer: Unknown
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi-
  I sat in on the ipng( should I saw IPv6) wg discussion today and heard some talk about different ways to do auto discovery of DNS. I don't know if anyone has already suggested this, but why not extend ICMP to support auto DNS discovery. It would be much like the router soliciation or net mask ICMP message pairs. I host sends out an ICMP dns request message and the recipient (broadcast or unicast) sends a reply with the name/ip addr(s) of the DNSs it knows about. 
  I would argue in favor of an ICMP extension over DHCP or anyother scheme requiring a server in the network since ICMP is already EVERYWHERE and this extension would require little work. 

Thanks,
Paul

Paul Tasillo
Tivoli Systems
paul.tasillo@tivoli.com


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

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 10:14:24 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77HCOP00374
	for ipng-dist; Mon, 7 Aug 2000 10:12:24 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77HCF600367
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 10:12:15 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA14792
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 10:12:14 -0700 (PDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10803
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 10:12:13 -0700 (PDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 9EB54372; Mon,  7 Aug 2000 13:12:11 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 5E82038CE; Mon,  7 Aug 2000 13:12:11 -0400 (EDT)
Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id NAA0000569698; Mon, 7 Aug 2000 13:11:55 -0400 (EDT)
Date: Mon, 7 Aug 2000 13:11:55 -0400 (EDT)
From: Sowmini Varadhan <varadhan@zk3.dec.com>
Message-Id: <200008071711.NAA0000569698@anw.zk3.dec.com>
To: jinmei@isl.rdc.toshiba.co.jp, richdr@microsoft.com, tim@mentat.com
Subject: RE: Tunnel Encapsulation Limit Option in rfc2473
Cc: aconta@txc.com, deering@cisco.com, ipng@sunroof.eng.sun.com,
   varadhan@zk3.dec.com, vlad@zk3.dec.com
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk



tim> > > Continuing to insist that you haven't changed the 
tim> > fragmentation rules is
tim> > > not an accurate assessment of the situation once one 
tim> > considers the details
tim> > > of actual implementation.

jinmei> > (although we've never tried to implement the tunnel encapsulation
jinmei> > option in the KAME statck) I completely agree with Tim and Vlad; the
jinmei> > proposed rule for the new option contradicts with general rules
jinmei> > described in RFC2460, and the advantage of the new rule is not worth
jinmei> > modifying existing implementations (IMHO).

richdr> I'll agree with this also. This is a non-trivial & ugly change to the
richdr> fragmentation rules in RFC 2460.
richdr> 
richdr> It may be too late, but how about this idea - have two code points for the
richdr> Destination Options, one that indicates fragmentable Destination Options
richdr> (typically used after routing/fragment header) and one that indicates
richdr> non-fragmentable Destination Options (typically used before routing/fragment
richdr> header, or when there is a tunnel encapsulation option).

Instead of hacking up destination options, wouldn't it be cleaner to 
adopt Vlad's idea of a new tunnel-specific extension header that is 
unfragmentable, and is to be parsed by tunnel entry points only?

--Sowmini

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

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 10:21:54 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77HKa000400
	for ipng-dist; Mon, 7 Aug 2000 10:20:36 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77HKR600393
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 10:20:27 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA06723
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 10:20:26 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA22333
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 11:20:24 -0600 (MDT)
Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 Aug 2000 10:05:53 -0700 (Pacific Daylight Time)
Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023);
	 Mon, 7 Aug 2000 10:15:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00092.ED66B8B2"
Subject: RE: bind(2) ordering constraint
Date: Mon, 7 Aug 2000 10:14:21 -0700
Message-ID: <19398D273324D3118A2B0008C7E9A5690D8CF03E@SIT.platinum.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: bind(2) ordering constraint
Thread-Index: Ab/9ZlRPQcywU/VKQ/Gj1JLaJc9XNQDLJujw
From: "Dave Thaler" <dthaler@Exchange.Microsoft.com>
To: <itojun@iijlab.net>
Cc: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 07 Aug 2000 17:15:01.0313 (UTC) FILETIME=[0528DB10:01C00093]
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C00092.ED66B8B2
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

::/9999 binds IPv6 only.
0.0.0.0/9999 binds IPv4 only.
They're completely independent.

-Dave

> -----Original Message-----
> From: itojun@iijlab.net [mailto:itojun@iijlab.net]
> Sent: Thursday, August 03, 2000 9:18 AM
> To: Dave Thaler
> Cc: ipng@sunroof.eng.sun.com
> Subject: Re: bind(2) ordering constraint
>=20
>=20
>=20
> >Platform: Windows
> >Version: 2000
> >Comment: Output is identical to Itojun's netbsd output, except in
> >         two cases where multiple error codes apply and Windows
> >         chooses to generate a different one.
> >
> >wild6 then wild4
> >	bind socket for ::/9999
> >	bind socket for 0.0.0.0/9999
>=20
> 	this one contradicts from what you've told me yesterday...
> 	maybe i heard you wrong.
>=20
> itojun
>=20

------_=_NextPart_001_01C00092.ED66B8B2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>RE: bind(2) ordering constraint</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>::/9999 binds IPv6 only.</FONT>

<BR><FONT SIZE=3D2>0.0.0.0/9999 binds IPv4 only.</FONT>

<BR><FONT SIZE=3D2>They're completely independent.</FONT>
</P>

<P><FONT SIZE=3D2>-Dave</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=3D2>&gt; From: itojun@iijlab.net [<A =
HREF=3D"mailto:itojun@iijlab.net">mailto:itojun@iijlab.net</A>]</FONT>

<BR><FONT SIZE=3D2>&gt; Sent: Thursday, August 03, 2000 9:18 AM</FONT>

<BR><FONT SIZE=3D2>&gt; To: Dave Thaler</FONT>

<BR><FONT SIZE=3D2>&gt; Cc: ipng@sunroof.eng.sun.com</FONT>

<BR><FONT SIZE=3D2>&gt; Subject: Re: bind(2) ordering constraint</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Platform: Windows</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Version: 2000</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;Comment: Output is identical to Itojun's =
netbsd output, except in</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; two cases where =
multiple error codes apply and Windows</FONT>

<BR><FONT SIZE=3D2>&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; chooses to generate =
a different one.</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;wild6 then wild4</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; bind socket for =
::/9999</FONT>

<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; bind socket for =
0.0.0.0/9999</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this one =
contradicts from what you've told me yesterday...</FONT>

<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; maybe i heard you =
wrong.</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>

<BR><FONT SIZE=3D2>&gt; itojun</FONT>

<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00092.ED66B8B2--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 11:26:22 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77ION100577
	for ipng-dist; Mon, 7 Aug 2000 11:24:23 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77IO2600547
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 11:24:03 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA26934
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 11:24:01 -0700 (PDT)
Received: from ziggy.stardust.com (ns.stardust.com [205.184.205.34])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14375
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 12:23:49 -0600 (MDT)
Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96])
	by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id LAA27949
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 11:11:17 -0700
Message-Id: <3.0.5.32.20000807111118.01466e80@stardust.com>
X-Sender: jasonu@stardust.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 07 Aug 2000 11:11:18 -0700
To: ipng@sunroof.eng.sun.com
From: Jason Utz <jasonu@stardust.com>
Subject: Call for IPv6 papers - iBAND at ISPCON
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e77IO3600548
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Greetings!

IPv6 is one of the core technologies covered at the iBAND events. We would
like to continue its progress at the upcoming iBAND at ISPCON Conference on
November 8-10, 2000, in San Jose, CA. iBAND at ISPCON is a gathering place
for key industry people to come together and learn about developments in
the new Internet technologies:

* Service Provisioning * Traffic Management * Performance Measurement *

Your iBAND at ISPCON participation will help expose network engineers and
other technology savvy professionals to the latest and greatest in IPv6
technology.
 
My name is Jason Utz, conference manager for iBAND at ISPCON Conference.
Stardust.com's CTO Martin Hall and I would like to invite you to share you
progress and ideas with other relevant professionals in one or more ways:

· Speaker Proposal * BOF Proposal * Showcase Participation *

We value your expertise and look forward to receiving your speaker
proposals to reflect the state of the art in IPv6 technology. Proposals are
due no later than Friday, August 18, 2000. To find guidance and more
information, please visit 

http://www.stardust.com/iband5/speakers.htm

http://www.stardust.com for network engineers offers additional
opportunities to supply information and progress for IPv6 updates and
technologies:

- conference sessions available in MP3 format,
- live interviews on Stardust.com TalkRadio,
- provide white papers and have them maintained in a Stardust.com Web library.

All these options provide you with a large arena to deliver your working
group's information and other updates. Please visit http://www.stardust.com
to see what our site offers to its visitors.

We want to help you drive this technology area forward so please let me
know how you'd like to participate. Please contact me via email with any
questions.


Best regards,

Jason Utz
Conference Manager
Stardust.com
Jasonu@stardust.com
www.stardust.com

***************** Stardust.com*********************
	            Visit Stardust.com
	       http://www.stardust.com
	   Making sense of new Internet stuff
    Visit Stardust Talkradio Mondays in MP3 Format!
***************************************************
Home of the IP Multicast Initiative (IPMI)
the QoS Forum (QOSF) and the
Wireless Multimedia Forum (WMF) NEW!
***************************************************
UPCOMING EVENTS:
*iBAND at ISPCON - Nov. 8-10, 2000, San Jose, CA
*WISE, The Wireless Internet Services Event - Nov. 6-7, San Jose, CA
*****************************************************
Jason Utz          
Conference Manager

15575 Los Gatos Blvd Suite C        Fax  408/402-0567
Los Gatos, CA 95032 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 11:45:20 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77IhSB00734
	for ipng-dist; Mon, 7 Aug 2000 11:43:28 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77IhO600727
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 11:43:24 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA18451
	for ipng@sunroof.eng.sun.com; Mon, 7 Aug 2000 11:41:29 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73Jw0627484
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:58:00 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA09089
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:57:53 -0700 (PDT)
Received: from ouaf.tycool.net (ouaf.tycool.net [207.171.238.84])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24657
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 12:57:41 -0700 (PDT)
Received: from rouget (ouaf.tycool.net [207.171.238.84])
	by ouaf.tycool.net (8.9.3+Sun/8.9.3) with SMTP id MAA06429;
	Thu, 3 Aug 2000 12:55:50 -0700 (PDT)
Message-ID: <008f01bffd85$9239c340$a0844993@tycool.net>
From: "Alain Durand" <alain.durand@Sun.COM>
To: =?iso-8859-1?Q?Stig_Ven=E5s?= <venaas@alfa.itea.ntnu.no>,
   "Matt Crawford" <crawdad@fnal.gov>
Cc: <ipng@sunroof.eng.sun.com>
References: <200008031807.NAA26676@gungnir.fnal.gov> <20000803214545.B9415@itea.ntnu.no>
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02
Date: Thu, 3 Aug 2000 13:01:09 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> On Thu, Aug 03, 2000 at 01:07:35PM -0500, Matt Crawford wrote:
> > Please remove the suggestion that DNS servers 'fabricate
> > "dummy" answers'!  The alternative, that nodes register
> > random names, is fine.
> 
> How about registering a PTR record for the prefix, if some server can't
> find a PTR record for the address, it could at least find out who owns
> the prefix. The result would be just as meaningful as a zone full of
> random names.
> 
> Stig


My suggestion was to use a wildcard PTR record for the /64 subnet.

    - Alain.


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

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 11:45:50 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77IiYK00753
	for ipng-dist; Mon, 7 Aug 2000 11:44:34 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77IiS600746
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 11:44:29 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA18480
	for ipng@sunroof.eng.sun.com; Mon, 7 Aug 2000 11:42:33 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e73Kc2627513
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 13:38:02 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA12645
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 13:38:01 -0700 (PDT)
Received: from drugs.dv.isc.org (wireless-135-228.ietf.marconi.com [147.73.135.228])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20074
	for <ipng@sunroof.eng.sun.com>; Thu, 3 Aug 2000 13:37:58 -0700 (PDT)
Received: from nominum.com (localhost.dv.isc.org [127.0.0.1])
	by drugs.dv.isc.org (8.9.3/8.9.3) with ESMTP id GAA52973
	for <ipng@sunroof.eng.sun.com>; Fri, 4 Aug 2000 06:39:30 +1000 (EST)
	(envelope-from marka@nominum.com)
Message-Id: <200008032039.GAA52973@drugs.dv.isc.org>
To: ipng@sunroof.eng.sun.com
From: Mark.Andrews@nominum.com
Subject: A6 and Site / Link Local
Date: Fri, 04 Aug 2000 06:39:30 +1000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


	Currently A6 records w/ prefix 0 do not have a prefix
	domain name.  Redefining A6 records with prefix 0 to
	have a domain name and to use this name as a site /
	link local identifier is still possible at this point
	in time.

	Doing this would provide a mechanism to identify which
	of a number of addresses you which to use.

	Mark

-- 
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: Mark.Andrews@nominum.com

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

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 12:24:37 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e77JNHY00961
	for ipng-dist; Mon, 7 Aug 2000 12:23:17 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e77JN6600954
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 12:23:06 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA09744
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 12:23:04 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17518
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 12:23:03 -0700 (PDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA11535
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 14:23:02 -0500 (CDT)
Message-Id: <200008071923.OAA11535@gungnir.fnal.gov>
To: ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: A6 and Site / Link Local 
In-reply-to: Your message of Fri, 04 Aug 2000 06:39:30 +1000.
             <200008032039.GAA52973@drugs.dv.isc.org> 
Date: Mon, 07 Aug 2000 14:23:02 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Mark explained this idea to me in Pittsburgh and once I finally
understood it, it seemed extremely useful at a very low cost.
Essentially, you'd leave the A6 records for the shortest global
prefixes alone, but put site-local and, if you wish, link-local
prefixes into your DNS, putting a DNS name of your choice into the
final A6 record with prefix length=0.  Example:


$ORIGIN example.com.
myhost          A6 64 ::1234:5678:9abc:def0 subnet-one.ip6
subnet-one.ip6  A6 48 0:0:0:1::  ip6
                A6  0 fe80:0:0:: link-one
ip6             A6 48 0::0       example-com-usa.ip6.my-isp.net.
                A6  0 fec0:0:0:: usa-hq
yourhost	A6 64 ::0246:8ace:1357:9bdf subnet-two.ip6
subnet-two.ip6  A6 48 0:0:0:2::  ip6
                A6  0 fe80:0:0:: link-two
herhost         A6 64 ::048c:159d:26ae:37bf subnet-eins.ip6
subnet-eins.ip6 A6 48 0:0:0:1    ip6de
                A6  0 fe80:0:0:: link-eins
ip6de           A6 48 0::0       example-com-de.ip6.andere-isp.de.
                A6  0 fec0:0:0:: de-site
usa-hq          TXT "There need not be any record at this label."
de-hq           TXT "There need not be any record at this label either."

So now if myhost looks up yourhost it gets a site-local address as
well as a global address.  The last RR of yourhost's site-local A6
chain has the same "prefix name" field as the last RR of myhost's
site-local A6 chain, so myhost can conclude that yourhost is on the
same site.  Similarly, it can conclude that yourhost is not on the
same link as my host, and that herhost is not on the same link or
site.

> 	Currently A6 records w/ prefix 0 do not have a prefix
> 	domain name.  Redefining A6 records with prefix 0 to
> 	have a domain name and to use this name as a site /
> 	link local identifier is still possible at this point
> 	in time.
> 
> 	Doing this would provide a mechanism to identify which
> 	of a number of addresses you which to use.

Today I thought of one possible simplification.  Couldn't the *owner
name* of the final A6 record in a chain be used for the same purpose?

______________________________________________________________________________
Matt Crawford                    crawdad@fnal.gov                     Fermilab
"A5.1.5.2.7.1. Remove all classified and CCI boards from the COMSEC equipment,
thoroughly smash them with a hammer or an ax, and scatter the 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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 20:14:03 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e783Cgt01711
	for ipng-dist; Mon, 7 Aug 2000 20:12:42 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e783CY601704
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:12:34 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA19359
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:12:32 -0700 (PDT)
Received: from 21cn.com ([202.104.32.241])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA15848
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 21:12:32 -0600 (MDT)
Received: from jeff([202.106.4.160]) by 21cn.com(JetMail 2.5.3.0)
	with SMTP id jm23398fe748; Tue,  8 Aug 2000 03:11:22 -0000
Message-ID: <001401c000e6$8bcfbfa0$bf0218ac@etdrc>
From: "zhang feng" <zhangfn@21cn.com>
To: <ipng@sunroof.eng.sun.com>
Subject: IPv6 AND FIXED ROUTER
Date: Tue, 8 Aug 2000 11:12:43 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0011_01C00129.9302E020"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C00129.9302E020
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

aG93IGRvIHlvdSB0aGluayB0aGF0IHdlIHVzZSBJUHY2IGFuZCBmaXhlZCByb3V0ZXIgaW4gb3Vy
IGJhY2tib25lPw0KSSB0aGluayBpdCBpcyBleGNlbGxlbnQsYmVjYXVzZSB0aGlzIGNhbiByZW1v
dmUgdGhlICByb3V0ZSBsb29rdXAgd2hpY2ggY2FuIGJlIHRoZSBrZXkgcHJvYmxlbSBlZmZlY3Rp
bmcgdGhlIHNwZWVkLg0KYW5kIHNvIHdlIGNhbiBzaW1wbGlmaWVkIHRoZSBuZXR3b3JrLGFuZCBw
cm9tb3RpbmcgdGhlIG5ldHdvcmsgc3BlZWQuDQpJIHRoaW5rIHRoYXQgdGhpcyBpcyBhcyBnb29k
IGFzIG1wbHMgYnV0IHRoZSBhcmNodGVjdHVyZSBpcyBzaW1wbGUuDQpIT1cgZG8geW91IHRoaW5r
IGFib3V0IGl0Pw0KSSBhbSBsb29raW5nIGZvcndvcmQgZGljdXNzaW5nIHdpdGggeW91Lg0Kc2lu
Y2VyZWx5DQp6aGFuZw0K

------=_NextPart_000_0011_01C00129.9302E020
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi
MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4w
MC4yMzE0LjEwMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5ob3cgZG8geW91IHRoaW5r
IHRoYXQgd2UgdXNlIElQdjYgYW5kIGZpeGVkIHJvdXRlciBpbiBvdXIgDQpiYWNrYm9uZT88L0ZP
TlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIHRoaW5rIGl0IGlzIGV4Y2VsbGVudCxiZWNh
dXNlIHRoaXMgY2FuIHJlbW92ZSB0aGUmbmJzcDsgDQpyb3V0ZSBsb29rdXAgd2hpY2ggY2FuIGJl
IHRoZSBrZXkgcHJvYmxlbSBlZmZlY3RpbmcgdGhlIHNwZWVkLjwvRk9OVD48L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPmFuZCBzbyB3ZSBjYW4gc2ltcGxpZmllZCB0aGUgbmV0d29yayxhbmQgcHJv
bW90aW5nIHRoZSBuZXR3b3JrIA0Kc3BlZWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl
PTI+SSB0aGluayB0aGF0IHRoaXMgaXMgYXMgZ29vZCBhcyBtcGxzIGJ1dCB0aGUgYXJjaHRlY3R1
cmUgaXMgDQpzaW1wbGUuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SE9XIGRvIHlv
dSB0aGluayBhYm91dCBpdD88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGFtIGxv
b2tpbmcgZm9yd29yZCBkaWN1c3Npbmcgd2l0aCB5b3UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O
VCBzaXplPTI+c2luY2VyZWx5PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+emhhbmc8
L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------=_NextPart_000_0011_01C00129.9302E020--

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

From owner-ipng@sunroof.eng.sun.com Mon Aug  7 21:00:50 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e783xSE01743
	for ipng-dist; Mon, 7 Aug 2000 20:59:28 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e783xJ601736
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:59:20 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA08506
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 20:59:19 -0700 (PDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA01838
	for <ipng@sunroof.eng.sun.com>; Mon, 7 Aug 2000 21:59:18 -0600 (MDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 3682A388F; Mon,  7 Aug 2000 22:59:18 -0500 (CDT)
Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP
	id D7BAE3A42; Mon,  7 Aug 2000 22:59:17 -0500 (CDT)
Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM)
	id XAA0000024737; Mon, 7 Aug 2000 23:59:16 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008080359.XAA0000024737@yquarry.zk3.dec.com>
X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol
To: Bob Hinden <hinden@iprg.nokia.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "Privacy Extensions for Stateless Address Autoconfiguration in IPv6s" 
In-reply-to: Your message of "Thu, 03 Aug 2000 20:12:59 PDT."
             <4.3.2.7.2.20000803201118.0246a608@mailhost.iprg.nokia.com> 
Date: Mon, 07 Aug 2000 23:59:16 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Bob,

I have an issue. 

>4.  Implications of Changing Interface Identifiers
>
>   The IPv6 addressing architecture goes to great lengths to ensure that
>  interface identifiers are globally unique. During the IPng
>   discussions of the GSE proposal [GSE], it was felt that keeping
>   interface identifiers globally unique in practice might prove useful
>  to future transport protocols. Usage of the algorithms in this
>   document would eliminate that future flexibility.

Can we get more words that this spec does not eliminate users who want
to use identifiers that are globally unique by ignoring this entire
spec?

Also I waited to respond cause I asked 3 sys admins of very large
networks to tell me if they would shut this off on an IPv6
implementation.  All said yes and it appears the IETF had to play some
poltics here.  This is just plain silly for corporate Intranets.

Hence, I suggest that some words be stated that for corproate Intranet
traffic this is may be very unnecessary.

thanks
/jim

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

From owner-ipng@sunroof.eng.sun.com Tue Aug  8 10:37:22 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e78HZIt02167
	for ipng-dist; Tue, 8 Aug 2000 10:35:18 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e78HZ9602160
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 10:35:09 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA09869
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 10:35:08 -0700 (PDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05125
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 11:33:52 -0600 (MDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id EB773234D; Tue,  8 Aug 2000 13:29:38 -0400 (EDT)
Received: from oflume.zk3.dec.com (yflume.zk3.dec.com [16.140.16.14])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP id CB0251BE0
	for <ipng@sunroof.eng.sun.com>; Tue,  8 Aug 2000 13:29:38 -0400 (EDT)
Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM)
	id NAA0000006794; Tue, 8 Aug 2000 13:29:37 -0400 (EDT)
Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM)
	id AA02479; Tue, 8 Aug 2000 13:29:37 -0400
Message-Id: <39904380.59982B1B@zk3.dec.com>
Date: Tue, 08 Aug 2000 13:29:36 -0400
From: Vladislav Yasevich <vlad@zk3.dec.com>
Organization: Compaq Computer Corporation
X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
Mime-Version: 1.0
To: ipng@sunroof.eng.sun.com
Subject: Re: bind(2) ordering constraint
References: <200008021951.e72JpWW02883@ starfruit.itojun.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Finnaly getting around to this, here is Compaq's behavior.
We have completely shared port space similar to Mentat's
implementation.

Note:  I am currently in the process of implementing independent
port spaces for unspecified addresses only.  I am also thinking
about extending this to all addresses, but am not sure of all
the implications.

Anyway, here is the output:

starting tests, socktype = SOCK_DGRAM
wild4 then wild4
        bind socket for 0.0.0.0/6999
        bind socket for 0.0.0.0/6999
        failed bind for 0.0.0.0/6999, Address already in use
wild4 then wild6
        bind socket for 0.0.0.0/6999
        bind socket for ::/6999
        failed bind for ::/6999, Address already in use
wild4 then loop4
        bind socket for 0.0.0.0/6999
        bind socket for 127.0.0.1/6999
        failed bind for 127.0.0.1/6999, Address already in use
wild4 then loop6
        bind socket for 0.0.0.0/6999
        bind socket for ::1/6999
        failed bind for ::1/6999, Address already in use
wild4 then one4
        bind socket for 0.0.0.0/6999
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
wild4 then map4
        bind socket for 0.0.0.0/6999
        bind socket for ::ffff:127.0.0.1/6999
        failed bind for ::ffff:127.0.0.1/6999, Address already in use
wild6 then wild4
        bind socket for ::/6999
        bind socket for 0.0.0.0/6999
        failed bind for 0.0.0.0/6999, Address already in use
wild6 then wild6
        bind socket for ::/6999
        bind socket for ::/6999
        failed bind for ::/6999, Address already in use
wild6 then loop4
        bind socket for ::/6999
        bind socket for 127.0.0.1/6999
        failed bind for 127.0.0.1/6999, Address already in use
wild6 then loop6
        bind socket for ::/6999
        bind socket for ::1/6999
        failed bind for ::1/6999, Address already in use
wild6 then one4
        bind socket for ::/6999
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
wild6 then map4
        bind socket for ::/6999
        bind socket for ::ffff:127.0.0.1/6999
        failed bind for ::ffff:127.0.0.1/6999, Address already in use
loop4 then wild4
        bind socket for 127.0.0.1/6999
        bind socket for 0.0.0.0/6999
        failed bind for 0.0.0.0/6999, Address already in use
loop4 then wild6
        bind socket for 127.0.0.1/6999
        bind socket for ::/6999
        failed bind for ::/6999, Address already in use
loop4 then loop4
        bind socket for 127.0.0.1/6999
        bind socket for 127.0.0.1/6999
        failed bind for 127.0.0.1/6999, Address already in use
loop4 then loop6
        bind socket for 127.0.0.1/6999
        bind socket for ::1/6999
loop4 then one4
        bind socket for 127.0.0.1/6999
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
loop4 then map4
        bind socket for 127.0.0.1/6999
        bind socket for ::ffff:127.0.0.1/6999
        failed bind for ::ffff:127.0.0.1/6999, Address already in use
loop6 then wild4
        bind socket for ::1/6999
        bind socket for 0.0.0.0/6999
        failed bind for 0.0.0.0/6999, Address already in use
loop6 then wild6
        bind socket for ::1/6999
        bind socket for ::/6999
        failed bind for ::/6999, Address already in use
loop6 then loop4
        bind socket for ::1/6999
        bind socket for 127.0.0.1/6999
loop6 then loop6
        bind socket for ::1/6999
        bind socket for ::1/6999
        failed bind for ::1/6999, Address already in use
loop6 then one4
        bind socket for ::1/6999
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
loop6 then map4
        bind socket for ::1/6999
        bind socket for ::ffff:127.0.0.1/6999
one4 then wild4
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
one4 then wild6
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
one4 then loop4
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
one4 then loop6
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
one4 then one4
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
one4 then map4
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
map4 then wild4
        bind socket for ::ffff:127.0.0.1/6999
        bind socket for 0.0.0.0/6999
        failed bind for 0.0.0.0/6999, Address already in use
map4 then wild6
        bind socket for ::ffff:127.0.0.1/6999
        bind socket for ::/6999
        failed bind for ::/6999, Address already in use
map4 then loop4
        bind socket for ::ffff:127.0.0.1/6999
        bind socket for 127.0.0.1/6999
        failed bind for 127.0.0.1/6999, Address already in use
map4 then loop6
        bind socket for ::ffff:127.0.0.1/6999
        bind socket for ::1/6999
map4 then one4
        bind socket for ::ffff:127.0.0.1/6999
        bind socket for 0.0.0.1/6999
        failed bind for 0.0.0.1/6999, Can't assign requested address
map4 then map4
        bind socket for ::ffff:127.0.0.1/6999
        bind socket for ::ffff:127.0.0.1/6999
        failed bind for ::ffff:127.0.0.1/6999, Address already in use

-vlad
-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug  8 14:48:00 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e78LjSr02401
	for ipng-dist; Tue, 8 Aug 2000 14:45:28 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e78LjJ602394
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 14:45:19 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA15364
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 14:45:18 -0700 (PDT)
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18990
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 15:45:07 -0600 (MDT)
Received: by sentry.gw.tislabs.com; id RAA24927; Tue, 8 Aug 2000 17:47:26 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5)
	id xma024913; Tue, 8 Aug 00 17:46:56 -0400
Received: from english.tislabs.com (clipper.gw.tislabs.com [10.33.1.2])
	by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id RAA06763;
	Tue, 8 Aug 2000 17:43:53 -0400 (EDT)
Message-Id: <4.3.2.7.2.20000808173552.00c948f0@localhost>
X-Sender: ogud@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 Aug 2000 17:41:47 -0400
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu@iijlab.net>,
   ipng@sunroof.eng.sun.com
From: Olafur Gudmundsson <ogud@tislabs.com>
Subject: Re: ENDS0
In-Reply-To: <20000807.205859.85324769.kazu@Mew.org>
References: <4.3.2.7.2.20000804162712.00bffe10@localhost>
 <20000804.061347.74669516.kazu@Mew.org>
 <4.3.2.7.2.20000804162712.00bffe10@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

At 07:58 AM 8/7/00, =?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?= wrote:
>From: Olafur Gudmundsson <ogud@tislabs.com>
>Subject: Re: ENDS0
>
> > I discussed this with the IPng WG chairs yesterday, and
> > one of them suggested that the message-size draft actually mandate
> > EDNS0 for hosts with IPv6 installed. This is a stronger requirement
> > than I was willing to make, but the other chair suggested to
> > ask the working group if they thing this is a good idea.
>
>Just for clarification. Does this mean dropping my proposal? Or pick
>up both and put them into a draft of IPv6 host requirement?

Do both.


> > Discussions on if EDNS0 should be mandated for IPv6 capable hosts
> > should take place here on ipng mailing list.
>
>OK.
>
>I would like to propose as follows:
>
>(1) DNS resolvers MUST implement EDNS0 if they support IPv6 transport
>     or AAAA/A6. Such resolvers SHOULD specify 2048 (*1) bytes as
>     buffer size to servers. (This requires larger IPv6 reassemble
>     buffer than the minimum, ie 1500.)
>
># (*1) need to discuss an appropriate size
>
>(2) DNS servers MUST implement EDNS if they support IPv6 transport or
>     AAAA/A6. They MUST assume client's buffer size is 1024 (*2) if
>     clients doesn't specify their buffer size by ENDS0.
>
># (*2) 1024 comes from the IPv6 minimum MTU, 1280 = 256 + 1024.

As I mentioned in the DNSEXT meeting, 1024 is unacceptably low.
1220-1240 is the number I'm thinking about. This is driven by DNSSEC
and the need to have multiple large signatures in certain high level
zones such as ".", "COM" etc.

As for worries about this causing fragmentation I humbly disagree, for the
following reasons:
1. DNS query is unlikely to traverse multiple tunnels to local server.
2. DNS query to a remote server is unlikely to traverse through a
IPSEC tunnel.

Thus we do not need to worry about extension headers at all and
can go to the upper limit of what IPv6 allows.


         Olafur

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

From owner-ipng@sunroof.eng.sun.com Tue Aug  8 18:58:58 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e791v6e02711
	for ipng-dist; Tue, 8 Aug 2000 18:57:06 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e791uv602704
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 18:56:57 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA10108
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 18:56:56 -0700 (PDT)
Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA25081
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:56:56 -0600 (MDT)
Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8])
	by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA11940
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 10:56:54 +0900 (JST)
Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA26628 for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 10:56:53 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA08643 for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 10:56:53 +0900 (JST)
Date: Wed, 09 Aug 2000 10:56:44 +0900 (JST)
Message-Id: <20000809.105644.41726355.kazu@Mew.org>
To: ipng@sunroof.eng.sun.com
Subject: Re: ENDS0
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
 <kazu@iijlab.net>
In-Reply-To: <4.3.2.7.2.20000808173552.00c948f0@localhost>
References: <4.3.2.7.2.20000804162712.00bffe10@localhost>
	<20000807.205859.85324769.kazu@Mew.org>
	<4.3.2.7.2.20000808173552.00c948f0@localhost>
X-Mailer: Mew version 1.95b52 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

From: Olafur Gudmundsson <ogud@tislabs.com>
Subject: Re: ENDS0

> As I mentioned in the DNSEXT meeting, 1024 is unacceptably low.
> 1220-1240 is the number I'm thinking about. This is driven by DNSSEC
> and the need to have multiple large signatures in certain high level
> zones such as ".", "COM" etc.

Since my proposal is that DNS resolvers SHOULD specify their buffer
value (e.g. 2048), using the default size (1024, 1220-1240, or what
ever) is a rare case.

So, I'm not particular to 1024 and I agree with 1220-1240.

--Kazu
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug  8 19:51:48 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e792oCi02740
	for ipng-dist; Tue, 8 Aug 2000 19:50:12 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e792o1602733
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:50:02 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA20384
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:50:01 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA22541
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:50:00 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Aug 2000 19:49:55 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58)
	id <Q2QXAQTB>; Tue, 8 Aug 2000 19:49:48 -0700
Message-ID: <FB9575840F91DC4EACEB5CD6F573A20D0154E164@red-msg-20.redmond.corp.microsoft.com>
From: Brian Zill <bzill@microsoft.com>
To: "'Olafur Gudmundsson'" <ogud@tislabs.com>, ipng@sunroof.eng.sun.com
Subject: RE: ENDS0
Date: Tue, 8 Aug 2000 19:49:53 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> From: Olafur Gudmundsson [mailto:ogud@tislabs.com]
>
> I discussed this with the IPng WG chairs yesterday,
> and one of them suggested that the message-size draft
> actually mandate EDNS0 for hosts with IPv6 installed.
> This is a stronger requirement than I was willing to
> make, but the other chair suggested to ask the working
> group if they thing this is a good idea.

There may be another reason to do this as well, if someone can clarify for
me what I picked up in a casual conversation at IETF.  Is it the case that
EDNS0 also makes life easier for IPv6 nodes by allowing resolvers to issue a
single query to a DNS server that independently asks for both A6 (or AAAA)
and A records and get a single response back with both answers?  Right now,
I believe the only way to do this is to issue separate queries and coalesce
the results yourself.  (My apologies for not knowing all that much about
DNS)

Thanks,
--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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug  8 19:58:47 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e792vu702762
	for ipng-dist; Tue, 8 Aug 2000 19:57:56 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e792vj602755
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:57:46 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA17286
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:57:44 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA25164
	for <ipng@sunroof.eng.sun.com>; Tue, 8 Aug 2000 19:57:44 -0700 (PDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 Aug 2000 19:57:39 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58)
	id <Q2QXARGQ>; Tue, 8 Aug 2000 19:57:32 -0700
Message-ID: <FB9575840F91DC4EACEB5CD6F573A20D01550DCB@red-msg-20.redmond.corp.microsoft.com>
From: Brian Zill <bzill@microsoft.com>
To: ipng@sunroof.eng.sun.com, "'Alex Conta'" <aconta@txc.com>
Subject: RE: Comments on draft-conta-extensions-ipv6-tunnel-00.txt
Date: Tue, 8 Aug 2000 19:57:38 -0700 
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Alex,

I agree completely with Erik here, and heard much the same from others
present at the meeting.

--Brian

> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> 
> Alex,
> 
> I really really don't see the need for what the draft
> calls "symmetric bi-directional tunnels".
> 
> While such constructs might be used in the traffic
> engineering context the TE context comes with a control
> protocol (MPLS) for setting up the explicit paths and
> recovering from failure.  Getting MPLS to control
> IPv6-in-IPv6 tunnels would be a huge exercise of very
> questionable value.
> 
> Thus my personal opinion is that the draft should only 
> specify "regular" bi-directional tunnels.
> 
>    Erik
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 01:12:00 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e798ASU02907
	for ipng-dist; Wed, 9 Aug 2000 01:10:28 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e798AH602900
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 01:10:17 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA09825
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 01:10:15 -0700 (PDT)
Received: from lychee.itojun.org (h170.p083.iij4u.or.jp [210.130.83.170])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA29024
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 01:10:10 -0700 (PDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e7989g601372;
	Wed, 9 Aug 2000 17:09:42 +0900 (JST)
Message-Id: <200008090809.e7989g601372@itojun.org>
To: Olafur Gudmundsson <ogud@tislabs.com>
cc: Kazu Yamamoto (=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=)
  <kazu@iijlab.net>,
   ipng@sunroof.eng.sun.com
In-reply-to: ogud's message of Tue, 08 Aug 2000 17:41:47 -0400.
      <4.3.2.7.2.20000808173552.00c948f0@localhost> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: ENDS0 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Wed, 09 Aug 2000 17:09:42 +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


	I have sent a clarification to namedroppers.  please revisit my email
	(if you don't have one, I'll resend)

>As I mentioned in the DNSEXT meeting, 1024 is unacceptably low.
>1220-1240 is the number I'm thinking about. This is driven by DNSSEC
>and the need to have multiple large signatures in certain high level
>zones such as ".", "COM" etc.
>
>As for worries about this causing fragmentation I humbly disagree, for the
>following reasons:
>1. DNS query is unlikely to traverse multiple tunnels to local server.
>2. DNS query to a remote server is unlikely to traverse through a
>IPSEC tunnel.

	tunnel is NOT the issue.  the DNS UDP payload size requirement
	should be computed from minimum MTU (1280 in RFC2460) and minimum
	fragment reassembly requirement (1500 in RFC2460).

	IPv6 minimum MTU is 1280, so if you transmit any packet larger than
	1280 (UDP payload length > 1232) you will have chance for fragmentation.
	it is the reason why kazu picked 1024 (and note the use of SHOULD/MUST
	in his email).

>Thus we do not need to worry about extension headers at all and
>can go to the upper limit of what IPv6 allows.

	I don't understand why you say so.  Please check the logic behind
	IPv4 DNS UDP payload length.  It is set to 512, because minimum IPv4
	fragment reassembly size is 576.  the mergin between 576 and 512
	(576 - 512 = 64) came from IPv4 header, UDP header and possible IPv4
	options and extension headers.

	We *will* see extension headers in IPv6 DNS queries and replies.
	Please keep some room for them.

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 07:22:10 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e79EKMe03307
	for ipng-dist; Wed, 9 Aug 2000 07:20:22 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79EKB603300
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 07:20:11 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA24083
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 07:20:08 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24423
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 08:20:05 -0600 (MDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA27156;
	Wed, 9 Aug 2000 09:19:52 -0500 (CDT)
Message-Id: <200008091419.JAA27156@gungnir.fnal.gov>
To: Olafur Gudmundsson <ogud@tislabs.com>
Cc: ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: ENDS0 
In-reply-to: Your message of Tue, 08 Aug 2000 17:41:47 EDT.
             <4.3.2.7.2.20000808173552.00c948f0@localhost> 
Date: Wed, 09 Aug 2000 09:19:52 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> As for worries about this causing fragmentation I humbly disagree, for the
> following reasons:
> 1. DNS query is unlikely to traverse multiple tunnels to local server.
> 2. DNS query to a remote server is unlikely to traverse through a
> IPSEC tunnel.
> Thus we do not need to worry about extension headers at all and
> can go to the upper limit of what IPv6 allows.

Point 1 is probably valid, although it's possible there may be a
tunnel, perhaps even an IPSEC tunnel, to some centralized facility
for all "infrastructure" traffic including DNS.  Point 2 is less
clear, but let's take it as true.  Still, I don't think your
conclusion follows from the premises.

Allowing for one IPSEC tunnel-mode wrapping and nothing else requires
outer IP header		40
ESP wrapping		36 or more, typical
inner IP header		40
UDP header		 8
total			124 bytes -- allowing 1156 payload bytes,
which is probably less than you wanted.

If, on the other hand, the client uses EDNS0 to advertise the lesser
of its resolver DNS buffer size and its IPv6 reassembly buffer limit
(defaulting the latter to 1500 if it can't be determined by some API
function) and the server punts PMTU problems by pre-fragmenting down
to 1280, the "losing" cases are merely fragmented replies rather than
TCP retries or worse.
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 11:32:02 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e79IUQe03634
	for ipng-dist; Wed, 9 Aug 2000 11:30:26 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79IUL603627
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 11:30:22 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA20102
	for ipng@sunroof.eng.sun.com; Wed, 9 Aug 2000 11:28:24 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79FBV603379
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 08:11:31 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA18743
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 08:11:31 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01157
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 08:11:26 -0700 (PDT)
Received: from nominum.com (localhost.dv.isc.org [127.0.0.1])
	by drugs.dv.isc.org (8.9.3/8.9.3) with ESMTP id BAA56800;
	Thu, 10 Aug 2000 01:12:54 +1000 (EST)
	(envelope-from marka@nominum.com)
Message-Id: <200008091512.BAA56800@drugs.dv.isc.org>
To: "Matt Crawford" <crawdad@fnal.gov>
Cc: ipng@sunroof.eng.sun.com
From: Mark.Andrews@nominum.com
Subject: Re: A6 and Site / Link Local 
In-reply-to: Your message of "Mon, 07 Aug 2000 14:23:02 EST."
             <200008071923.OAA11535@gungnir.fnal.gov> 
Date: Thu, 10 Aug 2000 01:12:54 +1000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> Mark explained this idea to me in Pittsburgh and once I finally
> understood it, it seemed extremely useful at a very low cost.
> Essentially, you'd leave the A6 records for the shortest global
> prefixes alone, but put site-local and, if you wish, link-local
> prefixes into your DNS, putting a DNS name of your choice into the
> final A6 record with prefix length=0.  Example:
> 
> 
> $ORIGIN example.com.
> myhost          A6 64 ::1234:5678:9abc:def0 subnet-one.ip6
> subnet-one.ip6  A6 48 0:0:0:1::  ip6
>                 A6  0 fe80:0:0:: link-one
> ip6             A6 48 0::0       example-com-usa.ip6.my-isp.net.
>                 A6  0 fec0:0:0:: usa-hq
> yourhost	A6 64 ::0246:8ace:1357:9bdf subnet-two.ip6
> subnet-two.ip6  A6 48 0:0:0:2::  ip6
>                 A6  0 fe80:0:0:: link-two
> herhost         A6 64 ::048c:159d:26ae:37bf subnet-eins.ip6
> subnet-eins.ip6 A6 48 0:0:0:1    ip6de
>                 A6  0 fe80:0:0:: link-eins
> ip6de           A6 48 0::0       example-com-de.ip6.andere-isp.de.
>                 A6  0 fec0:0:0:: de-site
> usa-hq          TXT "There need not be any record at this label."
> de-hq           TXT "There need not be any record at this label either."
> 
> So now if myhost looks up yourhost it gets a site-local address as
> well as a global address.  The last RR of yourhost's site-local A6
> chain has the same "prefix name" field as the last RR of myhost's
> site-local A6 chain, so myhost can conclude that yourhost is on the
> same site.  Similarly, it can conclude that yourhost is not on the
> same link as my host, and that herhost is not on the same link or
> site.

	They can also be used to reference the appropriate value
	to fill in the sockaddr link field.
> 
> > 	Currently A6 records w/ prefix 0 do not have a prefix
> > 	domain name.  Redefining A6 records with prefix 0 to
> > 	have a domain name and to use this name as a site /
> > 	link local identifier is still possible at this point
> > 	in time.
> > 
> > 	Doing this would provide a mechanism to identify which
> > 	of a number of addresses you which to use.
> 
> Today I thought of one possible simplification.  Couldn't the *owner
> name* of the final A6 record in a chain be used for the same purpose?

	I doesn't work where the chains are of length 1.

	Mark
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@nominum.com

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

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 13:09:45 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e79K5cU03762
	for ipng-dist; Wed, 9 Aug 2000 13:05:38 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79K5T603755
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 13:05:30 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16291
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 13:05:28 -0700 (PDT)
Received: from relay1.nce.smtp.psi.net (relay1.nce.smtp.psi.net [38.9.152.2])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18694
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 13:05:26 -0700 (PDT)
Received: from [198.138.94.6] (helo=smtp.txc.com)
	by relay1.nce.smtp.psi.net with smtp (Exim 3.13 #3)
	id 13Mc6N-0001MZ-00; Wed, 09 Aug 2000 16:05:24 -0400
Received: from jade.txc.com by smtp.txc.com (4.1/SMI-4.1)
	id AA01789; Wed, 9 Aug 00 16:02:37 EDT
Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4)
	id QAA07821; Wed, 9 Aug 2000 16:08:49 -0400
Message-Id: <3991B99B.6DBABEA4@txc.com>
Date: Wed, 09 Aug 2000 16:05:47 -0400
From: Alex Conta <aconta@txc.com>
X-Mailer: Mozilla 4.72 [en] (Win98; I)
X-Accept-Language: en
Mime-Version: 1.0
To: Brian Zill <bzill@microsoft.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Comments on draft-conta-extensions-ipv6-tunnel-00.txt
References: <FB9575840F91DC4EACEB5CD6F573A20D01550DCB@red-msg-20.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Brian,

I thank you and Erik for your feedback. It is important for making
progress on the draft.

It seems that my perspective on the source routed tunnel comes from an
angle that needs to be clarified.  As I understand it, the role of the
bi-directional tunneling draft is to describe/define mechanisms, and
give one or several examples of their use. 

Traffic engineering is a darling to network operators. In a pure IP
network, a network manager alleviates traffic bottle-necks, by
redirecting certain flows of traffic away from congested dynamically
routed IP paths.  This can be or is done by way of creating tunnels that
are pinned to sets of nodes distinct from those that are part of the
optimal paths chosen by dynamic routing. The pinning of routes is done
through source routing.  So, source routed tunnels is a valuable
mechanism. Furthermore, it is or can be used for many other purposes
besides the traffic engineering just mentioned.

Erik mentioned MPLS. For clarification, and to make sure we are on a
common ground, it is true that MPLS is well suited for traffic
engineering, but traffic engineering can be done and it is done 
in pure IP networks  independent of MPLS, as I gave an example above. 

In my view, source routed, or path pinned tunnels (whatever one wants to
call them), including bi-directional source routed tunnels would be part
of the description/defining of the set of mechanisms and examples of
their use, which is the role of a specification. Therefore, I believe
that in fact the draft is currently missing the mentioning or an
adequate documentation of source routed tunnels (unidirectional). By
adding such a documentation on uni-directional source routing, the
section on symmetric bi-directional tunnel would fall better in its
place as a bi-directional source routed tunnel. 

What seems to make sense to me is to question whether the text on source
routed tunnels be considered mechanisms or examples? If it was
considered mechanism would it be mandatory? No, I think.  I think it
would be a SHOULD, or MAY, even though for routers it is very useful.
Perhaps such clarification in the draft would help?

In light of this, I am confused by the suggestion of removing the
symmetrical bi-directional tunnels, and more clarification would help. 

Thanks,
Alex


Brian Zill wrote:
> 
> Hi Alex,
> 
> I agree completely with Erik here, and heard much the same from others
> present at the meeting.
> 
> --Brian
> 
> > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> >
> > Alex,
> >
> > I really really don't see the need for what the draft
> > calls "symmetric bi-directional tunnels".
> >
> > While such constructs might be used in the traffic
> > engineering context the TE context comes with a control
> > protocol (MPLS) for setting up the explicit paths and
> > recovering from failure.  Getting MPLS to control
> > IPv6-in-IPv6 tunnels would be a huge exercise of very
> > questionable value.
> >
> > Thus my personal opinion is that the draft should only
> > specify "regular" bi-directional tunnels.
> >
> >    Erik
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 13:43:47 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e79KgJE03803
	for ipng-dist; Wed, 9 Aug 2000 13:42:19 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79Kg7603796
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 13:42:08 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA05324
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 13:42:05 -0700 (PDT)
Received: from lychee.itojun.org (h066.p043.iij4u.or.jp [210.130.43.66])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11303
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 14:41:58 -0600 (MDT)
Received: from kiwi.itojun.org (localhost [127.0.0.1])
	by itojun.org (8.10.0/3.7W) with ESMTP id e79KfY610548;
	Thu, 10 Aug 2000 05:41:34 +0900 (JST)
Message-Id: <200008092041.e79KfY610548@itojun.org>
To: Mark.Andrews@nominum.com
cc: "Matt Crawford" <crawdad@fnal.gov>, ipng@sunroof.eng.sun.com
In-reply-to: Mark.Andrews's message of Thu, 10 Aug 2000 01:12:54 +1000.
      <200008091512.BAA56800@drugs.dv.isc.org> 
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: A6 and Site / Link Local 
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Date: Thu, 10 Aug 2000 05:41:34 +0900
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>> Mark explained this idea to me in Pittsburgh and once I finally
>> understood it, it seemed extremely useful at a very low cost.
>> Essentially, you'd leave the A6 records for the shortest global
>> prefixes alone, but put site-local and, if you wish, link-local
>> prefixes into your DNS, putting a DNS name of your choice into the
>> final A6 record with prefix length=0.  Example:
>> $ORIGIN example.com.
>> myhost          A6 64 ::1234:5678:9abc:def0 subnet-one.ip6
>> subnet-one.ip6  A6 48 0:0:0:1::  ip6
>>                 A6  0 fe80:0:0:: link-one
>> ip6             A6 48 0::0       example-com-usa.ip6.my-isp.net.
>>                 A6  0 fec0:0:0:: usa-hq
>> yourhost	A6 64 ::0246:8ace:1357:9bdf subnet-two.ip6
>> subnet-two.ip6  A6 48 0:0:0:2::  ip6
>>                 A6  0 fe80:0:0:: link-two
>> herhost         A6 64 ::048c:159d:26ae:37bf subnet-eins.ip6
>> subnet-eins.ip6 A6 48 0:0:0:1    ip6de
>>                 A6  0 fe80:0:0:: link-eins
>> ip6de           A6 48 0::0       example-com-de.ip6.andere-isp.de.
>>                 A6  0 fec0:0:0:: de-site
>> usa-hq          TXT "There need not be any record at this label."
>> de-hq           TXT "There need not be any record at this label either."
>> 
>> So now if myhost looks up yourhost it gets a site-local address as
>> well as a global address.  The last RR of yourhost's site-local A6
>> chain has the same "prefix name" field as the last RR of myhost's
>> site-local A6 chain, so myhost can conclude that yourhost is on the
>> same site.  Similarly, it can conclude that yourhost is not on the
>> same link as my host, and that herhost is not on the same link or
>> site.

	Matt, did you intentionally pick linklocal address as the example
	above?  I don't think you should put linklocal address onto globally
	reachable DNS name tree.  even site-local is questionable too.
	or do you expect some magical code in name server to filter fe80::
	prefixes out from remote queries?

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 14:13:03 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e79LApt03833
	for ipng-dist; Wed, 9 Aug 2000 14:10:51 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79LAc603826
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 14:10:38 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04037
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 14:10:35 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01807
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 14:10:22 -0700 (PDT)
Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com;
          Wed, 9 Aug 2000 16:05:15 -0500
Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QHJP0STL; Wed, 9 Aug 2000 14:04:42 -0700
Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.101]) 
          by zbl6c000.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QFFQK3TL; Wed, 9 Aug 2000 17:03:53 -0400
Message-ID: <3991C637.2395E3B7@nortelnetworks.com>
Date: Wed, 09 Aug 2000 16:59:35 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Brian Haberman" <haberman@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.74 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Margaret Wasserman <mrw@epilogue.com>
CC: IPng Mailing List <ipng@sunroof.eng.sun.com>
Subject: Re:
References: <4.2.2.20000802073100.01beef00@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret,

Margaret Wasserman wrote:
> 
> In an attempt to simplify my earlier example, I oversimplified
> it.  Here is a better diagram:
> 
> >The ICMP issue that you have described would also exist when using
> >multiple "conceptual" routing tables in the case of a partitioned
> >site. For example:
> 
> ==========================================================
> SITEA
>              Host1                      Host2
>                |                         |
>        ______._|_________    ___.______._|_____________
>        Link1 |                  |      |       Link2
>              |                (down)   |
>              |                  |      |
>              |+-----------------+      |
>              ||                        |
> ============R1========================R3===================
> SITEB       |                         |
>              |                         |
>         _____|_________________________|________________
>                                                  Link3
> 
> ===========================================================
> 
> Now, if Host1 sends a packet with site-local source and
> site-local destination, it obviously won't reach Host2.
> R1 will receive the packet, and will be unable to route
> the packet because there are no routes available in the
> conceptual site-local routing table for SITEA.  This
> will result in an ICMP/No Route to Destination error.
> The use of the conceptual routing table prevents R1 from
> noticing that there is a global route to Link2, so the
> potentially useful ICMP/Scope Exceeded error is not sent.

How will R1 know of a route to Link2 based on the site-local
addresses in the packet?  Will the routing protocol be able
to correlate which site-local prefixes are co-located with
global prefixes?  I am not sure that assumption can be made.

> 
> The user may see that some applications can reach Host2
> and other can not, but no pertinent error message will
> be displayed.  Also, "smart" applications do not receive
> the information that addresses of a greater scope
> could potentially reach the destination.
> 
> But, if Host1 sends a packet with site-local source and
> global destination through the same path, the ICMP/Scope
> Exceeded message will be returned.
> 
> Is it is important to maintain the "Scope Exceeded" message
> _only_ for packets where the destination scope is greater
> than the source scope?  Even if it means that we may discard
> packets that could successfully reach the destination in
> some cases (as in my first example)?
> 
> A mixed scope packet where the source is greater than the
> destination is the _only_ time that a Scope Exceeded message
> will be generated in the current architecture.  And, it

Ah, the intent was that the Scope Exceeded message is used when
the destination is greater than the source.  If the source
address is greater than the destination, the inability to route
the packet should be due to the lack of routing information for
the source prefix.


Brian

-- 
Brian Haberman
Nortel Networks
haberman@nortelnetworks.com
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 14:30:16 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e79LSXF03863
	for ipng-dist; Wed, 9 Aug 2000 14:28:33 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e79LS7603853
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 14:28:09 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA18253
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 14:27:57 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15267
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 15:27:37 -0600 (MDT)
Received: from zsc4c002.corpwest.baynetworks.com by smtprch1.nortel.com;
          Wed, 9 Aug 2000 16:19:29 -0500
Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) 
          by zsc4c002.corpwest.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QHJP0T7P; Wed, 9 Aug 2000 14:19:05 -0700
Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.101]) 
          by zbl6c000.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) 
          id QFFQK3T9; Wed, 9 Aug 2000 17:18:15 -0400
Message-ID: <3991C995.DF71AE6B@nortelnetworks.com>
Date: Wed, 09 Aug 2000 17:13:57 -0400
X-Sybari-Space: 00000000 00000000 00000000
From: "Brian Haberman" <haberman@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.74 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Margaret Wasserman <mrw@epilogue.com>
CC: IPng Mailing List <ipng@sunroof.eng.sun.com>
Subject: Re: Scoped Addressing Architecture Routing Issue
References: <4.2.2.20000801165220.0145bde0@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Margaret,
     Another piece of info that may be missing.  If a non-global
scoped address (source or destination) is forwarded outside of its
zone, there is no way to determine where it belongs.  The discussion
that Steve D. and I had was that Scope Exceeded message would indicate
to a sender that a source address was trying to be forwarded out of
its zone.  I will try and build a table that specifies when the
Scope Exceeded message should be used.

Brian

Margaret Wasserman wrote:
> 
> Hi Rich,
> 
> >Your example also has the best route between H1 & H2 in site B, be to go
> >through site A. This seems really unlikely to occur in actual practice. You
> >seem to be implicitly assuming that the two sites are in a single IGP
> >routing domain.
> 
> I am assuming that two sites _may_ be in the same routing domain, and
> that problems could occur in that situation.  I don't believe that the
> current IPv6 specifications assume that a single routing domain will
> always be a single site.
> 
> My example packet could easily occur in response to a packet sent from
> a host that doesn't have a site-local address (perhaps because it was
> configured via DHCP?).  That host would need to use a global address to
> communicate with a site-local address, and the response would have
> a site-local source and a global destination.
> 
> The ICMP issue that you have described would also exist when using
> multiple "conceptual" routing tables in the case of a partitioned
> site.  For example:
> 
> ==========================================================
> SITEA
>        Host1                      Host2
>          |                          |
> ________|__.__._____  ____.______._|_____________
>    Link1    |  |           |      |     Link2
>             |  |          (down)  |
>             |  +-----R1----+      |
>             |                     |
>             |                     |
> ===========|=====================|=========================
> SITEB      |                     |
>             +--------R1-----------+
> 
> ===========================================================
> 
> If a site-local packet (site-local destination and site-
> local source) is send from Host1 to Host2, it would
> probably be sent to the local router, R1.
> 
> R1 would then use the scoped addressing rules to forward the
> packet.  First, he would look at the destination address
> to determine that he should look in the site-local table.
> The site-local table would have no active route to Link2,
> so he would send a Destination Unreachable/No Route
> To Destination message, _not_ a Scope Exceeded message.
> 
> In this case, it might actually be _useful_ for the sender
> to receive a Scope Exceeded message, because the sender might
> be able to switch to global communication.  The sender may
> have had both site-local and global addresses available, but
> have chosen site-local communication.  But, he doesn't get the
> Scope Exceeded message, so he can't act on it.
> 
> However, if a mixed scope packet is sent (global destination
> and site-local source) from Host1 to Host2, R1 would look
> in the global table, determine that a route exists to Link2
> through R2, THEN discard the packet because of the site-local
> source.  This would result in a Destination Unreachable/Scope
> Exceeded message.  It seems unlikely, though, that Host1 would
> have sent a mixed-scope packet if he had a global address
> available for Host2, so the Scope Exceeded message is potentially
> _less_ useful in this situation.
> 
> 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 majordomo@sunroof.eng.sun.com
> --------------------------------------------------------------------

-- 
Brian Haberman
Nortel Networks
haberman@nortelnetworks.com
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug  9 20:05:33 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7A34Bj04169
	for ipng-dist; Wed, 9 Aug 2000 20:04:11 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7A346604162
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 20:04:06 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id UAA20566
	for ipng@sunroof.eng.sun.com; Wed, 9 Aug 2000 20:02:09 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7A2W2604141
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 19:32:04 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA09441
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 19:32:01 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA02534
	for <ipng@sunroof.eng.sun.com>; Wed, 9 Aug 2000 20:31:58 -0600 (MDT)
Received: from nominum.com (localhost.dv.isc.org [127.0.0.1])
	by drugs.dv.isc.org (8.9.3/8.9.3) with ESMTP id MAA84781;
	Thu, 10 Aug 2000 12:32:45 +1000 (EST)
	(envelope-from marka@nominum.com)
Message-Id: <200008100232.MAA84781@drugs.dv.isc.org>
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Cc: "Matt Crawford" <crawdad@fnal.gov>, ipng@sunroof.eng.sun.com
From: Mark.Andrews@nominum.com
Subject: Re: A6 and Site / Link Local 
In-reply-to: Your message of "Thu, 10 Aug 2000 05:41:34 +0900."
             <200008092041.e79KfY610548@itojun.org> 
Date: Thu, 10 Aug 2000 12:32:45 +1000
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


> 
> >> Mark explained this idea to me in Pittsburgh and once I finally
> >> understood it, it seemed extremely useful at a very low cost.
> >> Essentially, you'd leave the A6 records for the shortest global
> >> prefixes alone, but put site-local and, if you wish, link-local
> >> prefixes into your DNS, putting a DNS name of your choice into the
> >> final A6 record with prefix length=0.  Example:
> >> $ORIGIN example.com.
> >> myhost          A6 64 ::1234:5678:9abc:def0 subnet-one.ip6
> >> subnet-one.ip6  A6 48 0:0:0:1::  ip6
> >>                 A6  0 fe80:0:0:: link-one
> >> ip6             A6 48 0::0       example-com-usa.ip6.my-isp.net.
> >>                 A6  0 fec0:0:0:: usa-hq
> >> yourhost	A6 64 ::0246:8ace:1357:9bdf subnet-two.ip6
> >> subnet-two.ip6  A6 48 0:0:0:2::  ip6
> >>                 A6  0 fe80:0:0:: link-two
> >> herhost         A6 64 ::048c:159d:26ae:37bf subnet-eins.ip6
> >> subnet-eins.ip6 A6 48 0:0:0:1    ip6de
> >>                 A6  0 fe80:0:0:: link-eins
> >> ip6de           A6 48 0::0       example-com-de.ip6.andere-isp.de.
> >>                 A6  0 fec0:0:0:: de-site
> >> usa-hq          TXT "There need not be any record at this label."
> >> de-hq           TXT "There need not be any record at this label either."
> >> 
> >> So now if myhost looks up yourhost it gets a site-local address as
> >> well as a global address.  The last RR of yourhost's site-local A6
> >> chain has the same "prefix name" field as the last RR of myhost's
> >> site-local A6 chain, so myhost can conclude that yourhost is on the
> >> same site.  Similarly, it can conclude that yourhost is not on the
> >> same link as my host, and that herhost is not on the same link or
> >> site.
> 
> 	Matt, did you intentionally pick linklocal address as the example
> 	above?  I don't think you should put linklocal address onto globally
> 	reachable DNS name tree.  even site-local is questionable too.
> 	or do you expect some magical code in name server to filter fe80::
> 	prefixes out from remote queries?

	No, but it is not unreasonable to have getipnodebyname() and / or
	getaddrinfo() use the "prefix" field to optionally filter non
	local addresses based on a local table of site / link local names
	and in getaddrinfo() case to fill in sin6_scope_id.

	Mark
> 
> itojun
> --------------------------------------------------------------------
> 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
> --------------------------------------------------------------------
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@nominum.com

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

From owner-ipng@sunroof.eng.sun.com Thu Aug 10 01:07:48 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7A85dC04287
	for ipng-dist; Thu, 10 Aug 2000 01:05:39 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7A85S604280
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 01:05:30 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA20675
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 01:05:19 -0700 (PDT)
Received: from hikari.iij.ad.jp (h130.p452.iij4u.or.jp [210.149.196.130])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23357
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 01:05:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by hikari.iij.ad.jp (8.10.2/8.10.2) with ESMTP id e7A84pv00657
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 17:04:56 +0900 (JST)
Date: Thu, 10 Aug 2000 17:04:51 +0900 (JST)
Message-Id: <20000810.170451.74164331.kazu@iijlab.net>
To: ipng@sunroof.eng.sun.com
Subject: Re: ENDS0 
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)
 <kazu@iijlab.net>
In-Reply-To: <200008090809.e7989g601372@itojun.org>
References: <4.3.2.7.2.20000808173552.00c948f0@localhost>
	<200008090809.e7989g601372@itojun.org>
X-Mailer: Mew version 1.95b52 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Subject: Re: ENDS0 

> 	I don't understand why you say so.  Please check the logic behind
> 	IPv4 DNS UDP payload length.  It is set to 512, because minimum IPv4
> 	fragment reassembly size is 576.  the mergin between 576 and 512
> 	(576 - 512 = 64) came from IPv4 header, UDP header and possible IPv4
> 	options and extension headers.

Sorry, itojun. I think you misunderstand this.

To my best knowledge:

512 is just defined by RFC 1034 as UDP payload size(ie. buffer size).

The maximum IPv4 hdr (60) + UDP hdr (8) + DNS UDP payload size (512)
equals to 580, which exceeds 576.

See Section 3.1, RFC 791:

    The number 576 is selected to allow a reasonable sized data block to
    be transmitted in addition to the required header information.  For
    example, this size allows a data block of 512 octets plus 64 header
    octets to fit in a datagram.  The maximal internet header is 60
    octets, and a typical internet header is 20 octets, allowing a
    margin for headers of higher level protocols.

You can see magic number 64, which I think is meaningless, at least
these days.

# 4 bytes are missing...

--Kazu
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 10 03:38:03 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7AAaSh04371
	for ipng-dist; Thu, 10 Aug 2000 03:36:28 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7AAaB604364
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 03:36:13 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA03002
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 03:35:46 -0700 (PDT)
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15955
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 04:35:40 -0600 (MDT)
Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1])
	by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA01317;
	Thu, 10 Aug 2000 19:35:32 +0900 (JST)
To: Kazu Yamamoto (=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=)
  <kazu@iijlab.net>
cc: ipng@sunroof.eng.sun.com
In-reply-to: kazu's message of Thu, 10 Aug 2000 17:04:51 JST.
      <20000810.170451.74164331.kazu@iijlab.net>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: ENDS0 
From: itojun@iijlab.net
Date: Thu, 10 Aug 2000 19:35:32 +0900
Message-ID: <1315.965903732@coconut.itojun.org>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>Sorry, itojun. I think you misunderstand this.
>To my best knowledge:
>512 is just defined by RFC 1034 as UDP payload size(ie. buffer size).
>The maximum IPv4 hdr (60) + UDP hdr (8) + DNS UDP payload size (512)
>equals to 580, which exceeds 576.

	we should save enough room this time, then:-)

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 10 06:11:06 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7AD9fV04444
	for ipng-dist; Thu, 10 Aug 2000 06:09:41 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7AD9V604437
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 06:09:33 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA28770
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 06:09:32 -0700 (PDT)
Received: from mailweb2.rediffmail.com ([202.54.124.147])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA28074
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 07:09:22 -0600 (MDT)
Received: (qmail 15081 invoked by uid 510); 10 Aug 2000 13:00:24 -0000
Date: 10 Aug 2000 13:00:24 -0000
Message-ID: <20000810130024.15080.qmail@mailweb2.rediffmail.com>
MIME-Version: 1.0
To: "ipng@sunroof.eng.sun.com" <ipng@sunroof.eng.sun.com>
Subject: With Ref. to 2465
From: "Murali Krishna Ch" <chmurali@rediffmail.com>
Content-ID: <Thu_Aug_10_18_30_24_IST_2000_0@mailweb2.rediffmail.com>
Content-type: text/plain
Content-Description: 
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi All,

I have a few doubts in RFC 2465. Can you pl. clarify?

I)

The ipv6IfLowerLayer of IPv6IfEntry table
refers to an instance of either ifIndex or ipAdEntAddr.
Does this mean ipv6IfIndex and ipv6IfLowerLayer are different?

For example, consider these cases:
  case 1) IPv6 running over PPP which is running over HDLC
  case 2) IPv6 running over IPv4 and IPv4 running over Ethernet

In case 1, does ipv6IfLowerLayer refers to PPP or HDLC?
Similarly, in case 2, does ipv6IfLowerLayer refers to IPv4 or Ethernet?


II)

Since ipv6RouteTable, ipv6 Address Prefix Table and ipv6 Address Table are 
not-accessible and does contain any RowStatus, does it mean that static/manual entries 
creation is not possible? If entries are to be created, how to proceed?


Thank your very much for your time.

Regards,
murali.



_________________________________________________
Get Your Free Email At, http://www.rediffmail.com

Partcipate in crazy Re.1 auctions at http://www.rediff.com/auctions



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

From owner-ipng@sunroof.eng.sun.com Thu Aug 10 14:48:50 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7ALl0404878
	for ipng-dist; Thu, 10 Aug 2000 14:47:00 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7ALjx604869
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 14:46:00 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04208
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 14:45:57 -0700 (PDT)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA03298
	for <ipng@sunroof.eng.sun.com>; Thu, 10 Aug 2000 15:45:22 -0600 (MDT)
Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 10 Aug 2000 14:36:06 -0700 (Pacific Daylight Time)
Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023);
	 Thu, 10 Aug 2000 14:45:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00314.28AC12AE"
Subject: getaddrinfo (RFC 2553)
Date: Thu, 10 Aug 2000 14:44:28 -0700
Message-ID: <19398D273324D3118A2B0008C7E9A56910C951AE@SIT.platinum.corp.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: getaddrinfo (RFC 2553)
Thread-Index: AcADFEIdmgcvam0VRgOjgGa0m4BnZg==
From: "Mohit Talwar" <mohitt@Exchange.Microsoft.com>
To: <ipng@sunroof.eng.sun.com>
X-OriginalArrivalTime: 10 Aug 2000 21:45:10.0800 (UTC) FILETIME=[42018900:01C00314]
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C00314.28AC12AE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi all,

the spec is not very explicit about this, so i'd like
to make sure...

if (hints->ai_socktype is 0), it is meant to indicate
that the caller will accept any protocol. =20

does this imply that if both UDP and TCP services
exist with the given name, getaddrinfo should return
addrinfo structures for both these protocols.  or=20
should one choose a default protocol (say TCP) and
return only TCP addrinfo structures?

thanx,
mohit.

------_=_NextPart_001_01C00314.28AC12AE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>getaddrinfo (RFC 2553)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>hi all,</FONT>
</P>

<P><FONT SIZE=3D2>the spec is not very explicit about this, so i'd =
like</FONT>

<BR><FONT SIZE=3D2>to make sure...</FONT>
</P>

<P><FONT SIZE=3D2>if (hints-&gt;ai_socktype is 0), it is meant to =
indicate</FONT>

<BR><FONT SIZE=3D2>that the caller will accept any protocol.&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>does this imply that if both UDP and TCP =
services</FONT>

<BR><FONT SIZE=3D2>exist with the given name, getaddrinfo should =
return</FONT>

<BR><FONT SIZE=3D2>addrinfo structures for both these protocols.&nbsp; =
or </FONT>

<BR><FONT SIZE=3D2>should one choose a default protocol (say TCP) =
and</FONT>

<BR><FONT SIZE=3D2>return only TCP addrinfo structures?</FONT>
</P>

<P><FONT SIZE=3D2>thanx,</FONT>

<BR><FONT SIZE=3D2>mohit.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00314.28AC12AE--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 11 07:14:07 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7BEBtg05443
	for ipng-dist; Fri, 11 Aug 2000 07:11:55 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7BEBh605436
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 07:11:44 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA04092
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 07:11:37 -0700 (PDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25115
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 08:11:34 -0600 (MDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 0CB0B2D9A; Fri, 11 Aug 2000 09:11:33 -0500 (CDT)
Received: from yquarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP
	id 862BC2F6F; Fri, 11 Aug 2000 09:11:32 -0500 (CDT)
Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM)
	id KAA0000027066; Fri, 11 Aug 2000 10:11:31 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008111411.KAA0000027066@yquarry.zk3.dec.com>
X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol
To: "Mohit Talwar" <mohitt@Exchange.Microsoft.com>
Cc: <ipng@sunroof.eng.sun.com>
Subject: Re: getaddrinfo (RFC 2553) 
In-reply-to: Your message of "Thu, 10 Aug 2000 14:44:28 PDT."
             <19398D273324D3118A2B0008C7E9A56910C951AE@SIT.platinum.corp.microsoft.com> 
Date: Fri, 11 Aug 2000 10:11:31 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Mohit,

>the spec is not very explicit about this, so i'd like
>to make sure...

It sure is not.  I need to ask XNET why they let this hole exist?

>if (hints->ai_socktype is 0), it is meant to indicate
>that the caller will accept any protocol. =20

I think it should be an ERROR.

>does this imply that if both UDP and TCP services
>exist with the given name, getaddrinfo should return
>addrinfo structures for both these protocols.  or=20
>should one choose a default protocol (say TCP) and
>return only TCP addrinfo structures?

I don't think picking a default is wise it should be an error.

thanks
/jim

thanx,
mohit.

------_=_NextPart_001_01C00314.28AC12AE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4417.0">
<TITLE>getaddrinfo (RFC 2553)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>hi all,</FONT>
</P>

<P><FONT SIZE=3D2>the spec is not very explicit about this, so i'd =
like</FONT>

<BR><FONT SIZE=3D2>to make sure...</FONT>
</P>

<P><FONT SIZE=3D2>if (hints-&gt;ai_socktype is 0), it is meant to =
indicate</FONT>

<BR><FONT SIZE=3D2>that the caller will accept any protocol.&nbsp; =
</FONT>
</P>

<P><FONT SIZE=3D2>does this imply that if both UDP and TCP =
services</FONT>

<BR><FONT SIZE=3D2>exist with the given name, getaddrinfo should =
return</FONT>

<BR><FONT SIZE=3D2>addrinfo structures for both these protocols.&nbsp; =
or </FONT>

<BR><FONT SIZE=3D2>should one choose a default protocol (say TCP) =
and</FONT>

<BR><FONT SIZE=3D2>return only TCP addrinfo structures?</FONT>
</P>

<P><FONT SIZE=3D2>thanx,</FONT>

<BR><FONT SIZE=3D2>mohit.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C00314.28AC12AE--
--------------------------------------------------------------------
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
--------------------------------------------------------------------
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 11 07:34:50 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7BEXJs05472
	for ipng-dist; Fri, 11 Aug 2000 07:33:19 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7BEX2605465
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 07:33:03 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10024
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 07:32:57 -0700 (PDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09849
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 08:32:55 -0600 (MDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 17699F4F; Fri, 11 Aug 2000 10:32:55 -0400 (EDT)
Received: from yquarry.zk3.dec.com (rock.zk3.dec.com [16.141.0.34])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP
	id C2ABE1432; Fri, 11 Aug 2000 10:32:54 -0400 (EDT)
Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM)
	id KAA0000029210; Fri, 11 Aug 2000 10:32:54 -0400 (EDT)
Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM)
	id AA03561; Fri, 11 Aug 2000 10:32:53 -0400
Message-Id: <39940E95.256C527E@zk3.dec.com>
Date: Fri, 11 Aug 2000 10:32:53 -0400
From: Vladislav Yasevich <vlad@zk3.dec.com>
Organization: Compaq Computer Corporation
X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha)
X-Accept-Language: en
Mime-Version: 1.0
To: Mohit Talwar <mohitt@Exchange.Microsoft.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: getaddrinfo (RFC 2553)
References: <19398D273324D3118A2B0008C7E9A56910C951AE@SIT.platinum.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Mohit

Look at draft-ietf-ipngwg-rfc2553bis-00.txt.  It is much
clearer on this issue.

> Mohit Talwar wrote:
> 
> hi all,
> 
> the spec is not very explicit about this, so i'd like
> to make sure...
> 
> if (hints->ai_socktype is 0), it is meant to indicate
> that the caller will accept any protocol.
> 
> does this imply that if both UDP and TCP services
> exist with the given name, getaddrinfo should return
> addrinfo structures for both these protocols.  or
> should one choose a default protocol (say TCP) and
> return only TCP addrinfo structures?

The first answer would be correct.

> 
> thanx,
> mohit.

-vlad 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 11 08:13:32 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7BFC7p05554
	for ipng-dist; Fri, 11 Aug 2000 08:12:07 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7BFBs605547
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 08:11:54 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA20013
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 08:11:49 -0700 (PDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25413
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 08:11:47 -0700 (PDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id A0EC13785; Fri, 11 Aug 2000 11:11:46 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 7B8753A64; Fri, 11 Aug 2000 11:11:46 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id LAA0000677583; Fri, 11 Aug 2000 11:11:30 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008111511.LAA0000677583@anw.zk3.dec.com>
To: Vladislav Yasevich <vlad@zk3.dec.com>
Cc: Mohit Talwar <mohitt@Exchange.Microsoft.com>, ipng@sunroof.eng.sun.com
Subject: Re: getaddrinfo (RFC 2553) 
In-reply-to: Your message of "Fri, 11 Aug 2000 10:32:53 EDT."
             <39940E95.256C527E@zk3.dec.com> 
Date: Fri, 11 Aug 2000 11:11:30 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Vlad,

>Look at draft-ietf-ipngwg-rfc2553bis-00.txt.  It is much
>clearer on this issue.

Just clearer about being wrong.  I think it insane to let any API
specifiy 0 as socktype that is just ill-behaved IMO.

Mohit,

My input to still applies.  I want to ask XNET to tell us why they want
to permit this from an IEEE perspective it seems ill-behaved as a
strategy.

But my guess is we will support more and more stupid absurd garbage for
getaddrinfo() with consesus and design by committee in the IETF.  

Think about whats happening behind this basic API, getaddrinfo should
not be architected to be a middleware API.  That is plain bad
engineering and is where are headed now and I will keep my I told you so
card on this.

regards,
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 11 10:04:10 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7BH2Yj05627
	for ipng-dist; Fri, 11 Aug 2000 10:02:34 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7BH2U605620
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 10:02:30 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA21440
	for ipng@sunroof.eng.sun.com; Fri, 11 Aug 2000 10:00:33 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7BEqX605503
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 07:52:34 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA05397
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 07:52:33 -0700 (PDT)
Received: from sr.unh.edu (bluemoon.sr.unh.edu [132.177.241.26])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24336
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 08:52:32 -0600 (MDT)
Received: from [132.177.241.206] (rcc-dhcp-241-06.sr.unh.edu [132.177.241.206])
	by sr.unh.edu (8.9.1a/8.9.1) with ESMTP id KAA481909;
	Fri, 11 Aug 2000 10:52:31 -0400 (EDT)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="============_-1246116934==_ma============"
X-Sender: whl@bluemoon.sr.unh.edu
Message-Id: <v0401170ab5b9c2984b4f@[132.177.241.206]>
Date: Fri, 11 Aug 2000 10:52:38 -0400
To: ipng@sunroof.eng.sun.com
From: "William H. Lenharth" <whl@unh.edu>
Subject: ESTI IPv6 Testing in France - NOTICE
Cc: Ray LaRocca <rglr@iol.unh.edu>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

--============_-1246116934==_ma============
Content-Type: text/plain; charset="us-ascii"


          NOTICE OF CHANGE FOR Ipv6 TESTING AT ETSI IN FRANCE
                                                OCT 2-6, 2000

The IP Group at UNH regrets to inform the Ipv6 community that it will be
unable to
support the test period scheduled in October at ETSI in France.   The Ipv6
group is
unable to provide sufficient personnel to support the testing event.   UNH
was approached by the Ipv6 forum to support test periods at some of its
events and we informed the Forum that we would support events the were, US
based and that were held
in a time frame that did not destroy student educational programs.   The
plan was to
initially support a test period in Washington DC  in the third week of
September. The
plan changed to France and the date to October to accommodate ETSI, this
made the event
difficult to support.   We waited until the last minute to say NO, we
apologize for any
negative repercussions.

 Thanks very much for your support, we look forward to serving you at
future testing programs.

William H. Lenharth, Dir. IP Consortium, UNH

***********************************************************************
--============_-1246116934==_ma============
Content-Type: text/enriched; charset="us-ascii"



          NOTICE OF CHANGE FOR Ipv6 TESTING AT ETSI IN FRANCE

                                                OCT 2-6, 2000


The IP Group at UNH regrets to inform the Ipv6 community that it will
be unable to

support the test period scheduled in October at ETSI in France.   The
Ipv6 group is

unable to provide sufficient personnel to support the testing event.  
UNH was approached by the Ipv6 forum to support test periods at some of
its events and we informed the Forum that we would support events the
were, US based and that were held

in a time frame that did not destroy student educational programs.  
The plan was to 

initially support a test period in Washington DC  in the third week of
September. The

plan changed to France and the date to October to accommodate ETSI,
this made the event

difficult to support.   We waited until the last minute to say NO, we
apologize for any

negative repercussions.  


 Thanks very much for your support, we look forward to serving you at
future testing programs.


William H. Lenharth, Dir. IP Consortium, UNH


***********************************************************************

--============_-1246116934==_ma============--

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

From owner-ipng@sunroof.eng.sun.com Fri Aug 11 10:30:54 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7BHTJY05660
	for ipng-dist; Fri, 11 Aug 2000 10:29:19 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7BHTA605653
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 10:29:11 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA12008
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 10:29:09 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00436
	for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 2000 11:29:08 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7BHSK653629;
	Fri, 11 Aug 2000 19:28:20 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA02160;
	Fri, 11 Aug 2000 19:28:19 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA29706;
	Fri, 11 Aug 2000 19:30:25 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008111730.TAA29706@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <kazu@iijlab.net>
cc: ipng@sunroof.eng.sun.com
Subject: Re: ENDS0 
In-reply-to: Your message of Wed, 09 Aug 2000 10:56:44 +0900.
             <20000809.105644.41726355.kazu@Mew.org> 
Date: Fri, 11 Aug 2000 19:30:25 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   From: Olafur Gudmundsson <ogud@tislabs.com>
   Subject: Re: ENDS0
   
   > As I mentioned in the DNSEXT meeting, 1024 is unacceptably low.
   > 1220-1240 is the number I'm thinking about. This is driven by DNSSEC
   > and the need to have multiple large signatures in certain high level
   > zones such as ".", "COM" etc.
   
   Since my proposal is that DNS resolvers SHOULD specify their buffer
   value (e.g. 2048), using the default size (1024, 1220-1240, or what
   ever) is a rare case.
   
   So, I'm not particular to 1024 and I agree with 1220-1240.
   
=> I propose:
 - 1024 (because of the rationate for 1280) for the *minimal* size
 - 2048 (more?) for the recommended and default size (ie. if someone
   wants less it MUST specify it and MUST NOT try too small).

Thanks

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug 15 16:36:29 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7FNYtJ09456
	for ipng-dist; Tue, 15 Aug 2000 16:34:55 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7FNYh609449
	for <ipng@sunroof.eng.sun.com>; Tue, 15 Aug 2000 16:34:43 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA02897
	for <ipng@sunroof.eng.sun.com>; Tue, 15 Aug 2000 16:34:42 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04584
	for <ipng@sunroof.eng.sun.com>; Tue, 15 Aug 2000 17:34:40 -0600 (MDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
	by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id QAA03926;
	Tue, 15 Aug 2000 16:34:35 -0700 (PDT)
Message-Id: <200008152334.QAA03926@boreas.isi.edu>
To: rfc-dist@ISI.EDU
Subject: RFC 2894 on Router Renumbering for IPv6
Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 15 Aug 2000 16:34:35 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2894

        Title:	    Router Renumbering for IPv6
        Author(s):  M. Crawford
        Status:     Standards Track
	Date:       August 2000
        Mailbox:    crawdad@fnal.gov
        Pages:      32
        Characters: 69135
        Obsoletes/Updates/SeeAlso:  None

        I-D Tag:    draft-ietf-ipngwg-router-renum-10.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2894.txt


IPv6 Neighbor Discovery and Address Autoconfiguration conveniently
make initial assignments of address prefixes to hosts.  Aside from
the problem of connection survival across a renumbering event, these
two mechanisms also simplify the reconfiguration of hosts when the
set of valid prefixes changes.
 
This document defines a mechanism called Router Renumbering ("RR")
which allows address prefixes on routers to be configured and
reconfigured almost as easily as the combination of Neighbor
Discovery and Address Autoconfiguration works for hosts.  It
provides a means for a network manager to make updates to the
prefixes used by and advertised by IPv6 routers throughout a site.

This document is a product of the IPNG Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <000815163218.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2894

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2894.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <000815163218.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug 16 11:27:07 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7GIPO810206
	for ipng-dist; Wed, 16 Aug 2000 11:25:24 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7GIOP610199
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 11:24:26 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA01517
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 11:24:03 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08631
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 12:23:51 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA08219
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 11:23:47 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7GINia04121
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 11:23:44 -0700
X-Virus-Scanned:  Wed, 16 Aug 2000 11:23:44 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdKpdAsI; Wed, 16 Aug 2000 11:23:36 PDT
Message-ID: <399ADC2A.9A8F594F@iprg.nokia.com>
Date: Wed, 16 Aug 2000 11:23:38 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: When should mobile nodes use their care-of address, etc...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hello,

During the last IETF, there was a discussion about when a mobile node
should use its care-of address for communications.  One possible answer
is "never".  Mobile IPv6 was designed to avoid extra signaling overhead
that might result from the use of the home address.  However, if the
mobile node can make the following assertions:

1. No mobility events will occur
2. The other endpoint does not need the mobile node's DNS name
3. The other endpoint is not concerned with the mobile node's
   home address

or, alternatively, if (3), and the mobile node does not expect to
receive any packets from the other endpoint, then it is likely to
be safe for the mobile node to use its care-of address.  These
considerations, by the way, are the same as for IPv4.  Another
interesting factor is what might be meant by (1).  If the layer-2
protocols handle local mobility over a wide enough range, then
there is a corresponding relaxation on how rarely the conditions
might be satisfied.

I claim that it is up to the application to make these determinations,
or else it is up to the context in which the user invokes the
applications.  Sometimes the same application may, or may not, have
requirements for smooth network connectivity in the face of mobility
events.  Anything that is considered a "session" is an example of
something that is likely to fail to satisfy the abovementioned
conditions.

During the IPng meeting, there was a proposal to create a mailing
list for discussion of these issues.  If the mailing list is already
in operation, I'd like to join up.  I hope this message will be
considered relevant.

This whole problem is merely a particular example of a much larger
issue regarding the association of application invocation context
and IP addressability.  For instance, if a user wishes to associate
various "identities" to various IP addresses, then the user might
try to get applications to select IP source addresses that appropriately
express the desired identity to the other endpoint of the application's
communication.  From this point, we "could" devolve into more extended
discussion about the dual role of the IP(v6) address as a way to
encode both an identity and a route.  I do not propose to regurgitate
that entire discussion again, but I do note that it is highly relevant.

Instead, I would like to point out that in particular the use of
anonymous IPv6 addresses has to be considered as something under
the control of the application invoked by the user.  Thus, it is not
realistically possible to specify default source selection rules for
the use of anonymized IPv6 addresses.  Sometimes a user wishes to
be anonymous, and sometimes a user does NOT wish to be anonymous.
I do not think it is appropriate for the network protocol stack to
try to second-guess the user's intentions.

This note is already too long, but there is much more to say.
I look forward to seeing whether others are as interested in these
issues.

Regards,
Charlie P.
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug 16 13:05:31 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7GK2WU10349
	for ipng-dist; Wed, 16 Aug 2000 13:02:32 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7GK24610342
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 13:02:04 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA26972
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 13:01:58 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA26485
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 13:01:37 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 16 Aug 2000 13:01:15 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <QA2YXXYR>; Wed, 16 Aug 2000 13:01:15 -0700
Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9B43@red-msg-06.redmond.corp.microsoft.com>
From: Richard Draves <richdr@microsoft.com>
To: "'Charles E. Perkins'" <charliep@iprg.nokia.com>
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: RE: When should mobile nodes use their care-of address, etc...
Date: Wed, 16 Aug 2000 13:00:56 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> During the last IETF, there was a discussion about when a mobile node
> should use its care-of address for communications.  One 
> possible answer
> is "never".  Mobile IPv6 was designed to avoid extra 
> signaling overhead
> that might result from the use of the home address.  However, if the
> mobile node can make the following assertions:
> 
> 1. No mobility events will occur
> 2. The other endpoint does not need the mobile node's DNS name
> 3. The other endpoint is not concerned with the mobile node's
>    home address
> 
> or, alternatively, if (3), and the mobile node does not expect to
> receive any packets from the other endpoint, then it is likely to
> be safe for the mobile node to use its care-of address.  These
> considerations, by the way, are the same as for IPv4.  Another
> interesting factor is what might be meant by (1).  If the layer-2
> protocols handle local mobility over a wide enough range, then
> there is a corresponding relaxation on how rarely the conditions
> might be satisfied.

I look at it slightly differently although the result might be the same. The
mobile node should use its care-of address only if there's a very high
probablility that a movement will not break the application. Either because
the duration of the connection is much shorter than usual inter-movement
time, or because the application can recover from broken connections.

> I claim that it is up to the application to make these determinations,
> or else it is up to the context in which the user invokes the
> applications.  Sometimes the same application may, or may not, have
> requirements for smooth network connectivity in the face of mobility
> events.  Anything that is considered a "session" is an example of
> something that is likely to fail to satisfy the abovementioned
> conditions.

Ì agree with this - it should be up to the application. For example, suppose
a mobile node with care-of address CA and home address HA is opening a TCP
connection to a server D. If it's a telnet connection, you presumably want
to use HA. If it's a short-lived HTTP request, you presumably want to use
CA. Note that the mobile node might have both kinds of connections to D
simultaneously. So policies based solely on the addresses involved (D, CA,
HA) will not work.

(One could consider policies that use port number/protocol, like IPsec
policies. The Zhao/Castellucia/Baker paper takes this approach. But
ultimately, it's really application/user knowledge that's needed here.)

> During the IPng meeting, there was a proposal to create a mailing
> list for discussion of these issues.  If the mailing list is already
> in operation, I'd like to join up.  I hope this message will be
> considered relevant.

I haven't heard of such a mailing list.
 
> This whole problem is merely a particular example of a much larger
> issue regarding the association of application invocation context
> and IP addressability.  For instance, if a user wishes to associate
> various "identities" to various IP addresses, then the user might
> try to get applications to select IP source addresses that 
> appropriately
> express the desired identity to the other endpoint of the 
> application's
> communication.  From this point, we "could" devolve into more extended
> discussion about the dual role of the IP(v6) address as a way to
> encode both an identity and a route.  I do not propose to regurgitate
> that entire discussion again, but I do note that it is highly 
> relevant.
> 
> Instead, I would like to point out that in particular the use of
> anonymous IPv6 addresses has to be considered as something under
> the control of the application invoked by the user.  Thus, it is not
> realistically possible to specify default source selection rules for
> the use of anonymized IPv6 addresses.  Sometimes a user wishes to
> be anonymous, and sometimes a user does NOT wish to be anonymous.
> I do not think it is appropriate for the network protocol stack to
> try to second-guess the user's intentions.

I also agree that the use of anonymous addresses should be under the control
of the application. This is why my draft suggests, in both the mobility rule
and the privacy rule, that implementations may support a socket option to
control the preference.

I think a default rule is possible & necessary. For mobility, the default
should be to use the home address so movement will not break connections.
For privacy, the default should be to use the anonymous address. Without
these defaults, in practice there wouldn't be benefit.

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug 16 20:01:33 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7H2xuH10573
	for ipng-dist; Wed, 16 Aug 2000 19:59:56 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7H2xl610566
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 19:59:48 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA26978
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 19:59:46 -0700 (PDT)
Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA11885
	for <ipng@sunroof.eng.sun.com>; Wed, 16 Aug 2000 19:59:46 -0700 (PDT)
Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345)
	id 3792C1DAD; Wed, 16 Aug 2000 22:59:46 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail02.zma.compaq.com (Postfix) with ESMTP
	id 0914F1CAB; Wed, 16 Aug 2000 22:59:46 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000847298; Wed, 16 Aug 2000 22:59:30 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008170259.WAA0000847298@anw.zk3.dec.com>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>, bound@zk3.dec.com
Subject: Re: When should mobile nodes use their care-of address, etc... 
In-reply-to: Your message of "Wed, 16 Aug 2000 11:23:38 PDT."
             <399ADC2A.9A8F594F@iprg.nokia.com> 
Date: Wed, 16 Aug 2000 22:59:29 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Hi Charlie,

This response is not as IETFer but as member of implementation team
working with customers to deploy Mobile IP and with GPRS GSM for now and
eventually ALL-IP and ALL Mobile IP for IPv4 and IPv6 on our platforms.

>During the last IETF, there was a discussion about when a mobile node
>should use its care-of address for communications.  One possible answer
>is "never".  Mobile IPv6 was designed to avoid extra signaling overhead
>that might result from the use of the home address.  However, if the
>mobile node can make the following assertions:

I think "never" is too restrictive a concept pretty much universally
except for death, but definitely invalid for protocol optimizations.

>1. No mobility events will occur
>2. The other endpoint does not need the mobile node's DNS name
>3. The other endpoint is not concerned with the mobile node's
>   home address

OK I will take these as assumptions.

>or, alternatively, if (3), and the mobile node does not expect to
>receive any packets from the other endpoint, then it is likely to
>be safe for the mobile node to use its care-of address.  These
>considerations, by the way, are the same as for IPv4.  Another
>interesting factor is what might be meant by (1).  If the layer-2
>protocols handle local mobility over a wide enough range, then
>there is a corresponding relaxation on how rarely the conditions
>might be satisfied.

If your last sentence is TRUE which is TRUE for deployment now as best I
can tell the relaxation is clearly OK.  But to sway those to support
this in the standards arena you will need other bullets too once (1) may
in fact occur because of ALL Mobile IP, not that I think we do, I think we
should just do this now and it makes sense but I am getting used to
hanging around and working on stuff just to do what I knew we would do
two years before we could actually do it. (yes it is confusing and so is
the sentence).  So we hopefully can proceeed to work this idea and beat it
until its a dead horse, make it PS, and then the benefit can be practiced.

Another issue is that roaming Cell Phones and PDAs and other handhelds
will not be the only Mobile Nodes.  A LapTop will roam but most likely
will be stationary for longer period of time satisfying (1).  And once
communications is established (2) and (3) are pretty safe bets too.

>I claim that it is up to the application to make these determinations,
>or else it is up to the context in which the user invokes the
>applications.  Sometimes the same application may, or may not, have
>requirements for smooth network connectivity in the face of mobility
>events.  Anything that is considered a "session" is an example of
>something that is likely to fail to satisfy the abovementioned
>conditions.

I suggest its a system parameter on the MN as I hope most
applications do not have to know the inner workings of Mobile IP.
It can be a system parameter that can support individual, group, or
system wide application granularity.  I don't think it should be an API
or 2 Year IETF effort to discuss it and define it and build a camel
instead of a horse.  What has to be done is a simple statement to permit
the behavior as extension to Mobile IPv4 and IPv6.  Clearly this needs
to be defended and discussed, but just the permission of it, and the market
will figure out how to use it.  thank you. 

>During the IPng meeting, there was a proposal to create a mailing
>list for discussion of these issues.  If the mailing list is already
>in operation, I'd like to join up.  I hope this message will be
>considered relevant.

Well me or someone on my team would like to join too when its known if it
exists or will exist.

>This whole problem is merely a particular example of a much larger
>issue regarding the association of application invocation context
>and IP addressability.  For instance, if a user wishes to associate
>various "identities" to various IP addresses, then the user might
>try to get applications to select IP source addresses that appropriately
>express the desired identity to the other endpoint of the application's
>>communication.  From this point, we "could" devolve into more extended
>discussion about the dual role of the IP(v6) address as a way to
>encode both an identity and a route.  I do not propose to regurgitate
>that entire discussion again, but I do note that it is highly relevant.

I suggest we don't go there.  From past history we will just go in
circles, cause a white paper to be written that does not solve the
problem, and this time we may even have a melt down and loose critical
IETF resources into the ozone.  But its your own trip.  But I have found
Trips on EIDs have been very bad Trips.  In fact you may have a social
responsibility if we could loose IETFers to the ozone to not go
there :----)

>Instead, I would like to point out that in particular the use of
>anonymous IPv6 addresses has to be considered as something under
>the control of the application invoked by the user.  Thus, it is not
>realistically possible to specify default source selection rules for
>the use of anonymized IPv6 addresses.  Sometimes a user wishes to
>be anonymous, and sometimes a user does NOT wish to be anonymous.
>I do not think it is appropriate for the network protocol stack to
>try to second-guess the user's intentions.

I agree 100%.  In fact I will take it further.  I think its a users
right to not believe in this entire privacy issue about IPv6 and decide
to live with the perceived risk (especially on private Intranets).  
Anonymous address processing will cost something on a node that uses them 
and users may not want the interference.  Users rule a the end of the day 
because they pay, and second guessing their intentions is not something
I will ever build as an engineer unless they ask me to.  Most users
assume personal responsbility for their intentions I know, and know the
trade-offs or ask people like me when it comes to networking.

>This note is already too long, but there is much more to say.

Good note though and good idea because if we can send to the
care-of-adress directly it is simply faster and heck to any user faster
is better.

>I look forward to seeing whether others are as interested in these
>issues.

Count me in Charlie,
thanks
/jim

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

From owner-ipng@sunroof.eng.sun.com Thu Aug 17 02:24:18 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7H9Mxt10709
	for ipng-dist; Thu, 17 Aug 2000 02:22:59 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7H9Mo610702
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 02:22:50 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA27516
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 02:22:49 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00028
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 02:22:48 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7H9MP653590;
	Thu, 17 Aug 2000 11:22:25 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA12561;
	Thu, 17 Aug 2000 11:22:20 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA56185;
	Thu, 17 Aug 2000 11:24:47 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008170924.LAA56185@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
cc: IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: Re: When should mobile nodes use their care-of address, etc... 
In-reply-to: Your message of Wed, 16 Aug 2000 11:23:38 PDT.
             <399ADC2A.9A8F594F@iprg.nokia.com> 
Date: Thu, 17 Aug 2000 11:24:47 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   During the last IETF, there was a discussion about when a mobile node
   should use its care-of address for communications.

=> yes, I asked for more flexibility in the (source) address selection
mechanism.

   One possible answer is "never".  Mobile IPv6 was designed to avoid
   extra signaling overhead that might result from the use of the home
   address.

=> "never" is the proposed solution in the current draft
(draft-ietf-ipngwg-default-addr-select-01.txt). IMHO a finer control
is needed. The current text is:

   >Rule 5: Prefer home addresses. 
   >If SA is a home address and SB is a care-of address, then prefer SA. 
   >Similarly, if SB is a home address and SA is a care-of address, then 
   >prefer SB. 
   >An implementation MAY support a per-connection configuration 
   >mechanism (for example, a socket option) to reverse the sense of 
   >this preference and prefer care-of addresses over home addresses. 

   However, if the mobile node can make the following assertions:
   
   1. No mobility events will occur

=> this can be enough to reverse the "never" in "always" but a
per-connection config is not enough. And of course there are many
cases between never and always, like "close enough" to home or
visited network.

   Another interesting factor is what might be meant by (1).

=> there is a good example of (1): the use of mobility for "smart"
nomadism, ie. for instance you have a laptop with an address in
Nokia labs in the Silicon Valley and when you go to Nokia labs
in the New England you'd like to keep this address for receiving
your mail through your prefered MTA, but use the local address for
all other things like printing documents.

   I claim that it is up to the application to make these determinations,

=> this is done by the per-connection (ie. socket option) hook.

   or else it is up to the context in which the user invokes the
   applications.

=> then you believe we need more flexibility here too?

   During the IPng meeting, there was a proposal to create a mailing
   list for discussion of these issues.  If the mailing list is already
   in operation, I'd like to join up.  I hope this message will be
   considered relevant.
   
=> as far as I know there is no other mailing list than the IPng one
for discussion of these issues. I wrote a proposal and sent it
to authors of the draft. We have done no progress since the end of
the IETF meeting (jetlag + holidays?) but I'd like to resume the
discussion if more work is needed...

   This whole problem is merely a particular example of a much larger
   issue regarding the association of application invocation context
   and IP addressability.  For instance, if a user wishes to associate
   various "identities" to various IP addresses, then the user might
   try to get applications to select IP source addresses that appropriately
   express the desired identity to the other endpoint of the application's
   communication.  From this point, we "could" devolve into more extended
   discussion about the dual role of the IP(v6) address as a way to
   encode both an identity and a route.  I do not propose to regurgitate
   that entire discussion again, but I do note that it is highly relevant.
   
=> I have coded a notion of proximity with longest prefix matching
(the one used in routing), is it enough?

   Instead, I would like to point out that in particular the use of
   anonymous IPv6 addresses has to be considered as something under
   the control of the application invoked by the user.  Thus, it is not
   realistically possible to specify default source selection rules for
   the use of anonymized IPv6 addresses.  Sometimes a user wishes to
   be anonymous, and sometimes a user does NOT wish to be anonymous.
   I do not think it is appropriate for the network protocol stack to
   try to second-guess the user's intentions.
   
=> Rule 7 is as inflexible as rule 5. Is the per-connection (socket option)
hook enough? I believe you'd like to have a per-context (binary) control.

   This note is already too long, but there is much more to say.
   I look forward to seeing whether others are as interested in these
   issues.
   
=> I am interested... There are two points I'd like to see explained:
 - add binary choices of rules 5 and 7 in the policy table in order to
   have finer control (note that for rule 5 binary is not enough).
 - what are the proposed granularities for the policy table (only one
   node-global table, an optional table in environment (per user, per
   session, per process-group, ...), ...).
And for the last point what difference between the source and destination
selection (implementations can be done at different layers)? I think
there should be no difference but they are some implementation trade-offs...

Regards

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 17 04:50:22 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7HBmtY10788
	for ipng-dist; Thu, 17 Aug 2000 04:48:55 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7HBmk610781
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 04:48:46 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA06415
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 04:48:45 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25421
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 04:48:44 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7HBmR645903;
	Thu, 17 Aug 2000 13:48:27 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA13797;
	Thu, 17 Aug 2000 13:48:26 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id NAA56904;
	Thu, 17 Aug 2000 13:51:04 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008171151.NAA56904@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Richard Draves <richdr@microsoft.com>
cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: Re: When should mobile nodes use their care-of address, etc... 
In-reply-to: Your message of Wed, 16 Aug 2000 13:00:56 PDT.
             <7695E2F6903F7A41961F8CF888D87EA81C9B43@red-msg-06.redmond.corp.microsoft.com> 
Date: Thu, 17 Aug 2000 13:51:03 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   I look at it slightly differently although the result might be the same. The
   mobile node should use its care-of address only if there's a very high
   probablility that a movement will not break the application.

=> for me if P(movement) = 0 then P(a movement will break the app) = 0
then if (1. No mobility events will occur) then care-of should be used.

   > I claim that it is up to the application to make these determinations,
   > or else it is up to the context in which the user invokes the
   > applications.  Sometimes the same application may, or may not, have
   > requirements for smooth network connectivity in the face of mobility
   > events.  Anything that is considered a "session" is an example of
   > something that is likely to fail to satisfy the abovementioned
   > conditions.
   
   Ì agree with this - it should be up to the application.

=> but your draft doesn't implement what Charlie has written...

   For example, suppose
   a mobile node with care-of address CA and home address HA is opening a TCP
   connection to a server D. If it's a telnet connection, you presumably want
   to use HA. If it's a short-lived HTTP request, you presumably want to use
   CA. Note that the mobile node might have both kinds of connections to D
   simultaneously. So policies based solely on the addresses involved (D, CA,
   HA) will not work.
   
=> then a single global policy table is not enough? I agree.

   (One could consider policies that use port number/protocol, like IPsec
   policies. The Zhao/Castellucia/Baker paper takes this approach. But
   ultimately, it's really application/user knowledge that's needed here.)
   
=> the draft proposes a solution for application knowledge (socket option)
but not user knowledge (or do you suggest to add to every applications
some arguments and code in order to control address selections, I believe
this is not your intent, then clearly your draft needs something...)

   I also agree that the use of anonymous addresses should be under the control
   of the application. This is why my draft suggests, in both the mobility rule
   and the privacy rule, that implementations may support a socket option to
   control the preference.
   
=> I believe a socket option is not enough and the control should be done
through the contextual policy table too.

   I think a default rule is possible & necessary.

=> I agree, freedom is not anarchy!
   
Francis.Dupont@enst-bretagne.fr

PS: can you explain how the control is done in your implementation?
PPS: perhaps an API for policy table control should be specified??
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 17 09:45:17 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7HGhfL10950
	for ipng-dist; Thu, 17 Aug 2000 09:43:41 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7HGhT610943
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 09:43:30 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25603
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 09:43:26 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA21057
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 10:43:24 -0600 (MDT)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Aug 2000 09:35:24 -0700 (Pacific Daylight Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58)
	id <Q2QY1LWW>; Thu, 17 Aug 2000 08:40:40 -0700
Message-ID: <2E3FA0558747934A8F753CC533A3F6DF043C32B6@red-msg-24.redmond.corp.microsoft.com>
From: Christian Huitema <huitema@microsoft.com>
To: "'Francis Dupont'" <Francis.Dupont@enst-bretagne.fr>,
   Richard Draves
	 <richdr@microsoft.com>
Cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group
	 <ipng@sunroof.eng.sun.com>
Subject: RE: When should mobile nodes use their care-of address, etc... 
Date: Thu, 17 Aug 2000 08:40:38 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

May I observe that, in attempting to specify a source address selection
algorithm, the WG goes well beyond the traditional IETF role, which is to
focus on interoperability issues, not implementations? I would expect such
algorithms to evolve in time, as we learn more on the subject. I would also
expect them to vary a lot depending on how much a particular station knows
about its environment, how far in the future it can predict the
application's behavior, what arbitration is made between privacy and
performance, etc. Rather than specify an actual algorithm, the WG should be
content with a list of recommendations, in the form of "if you do this,
expect that" or "don't do X, because it will cause interoperability problem
Y." 
-- 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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 17 18:18:03 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7I1FE211238
	for ipng-dist; Thu, 17 Aug 2000 18:15:14 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7I1F5611231
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 18:15:05 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA11856
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 18:15:04 -0700 (PDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA18187
	for <ipng@sunroof.eng.sun.com>; Thu, 17 Aug 2000 19:15:04 -0600 (MDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id A8FB43A99; Thu, 17 Aug 2000 21:15:03 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 750F43886; Thu, 17 Aug 2000 21:15:03 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id VAA0000546455; Thu, 17 Aug 2000 21:14:11 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008180114.VAA0000546455@anw.zk3.dec.com>
To: Christian Huitema <huitema@microsoft.com>
Cc: "'Francis Dupont'" <Francis.Dupont@enst-bretagne.fr>,
   Richard Draves <richdr@microsoft.com>,
   "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group <ipng@sunroof.eng.sun.com>, bound@zk3.dec.com
Subject: Re: When should mobile nodes use their care-of address, etc... 
In-reply-to: Your message of "Thu, 17 Aug 2000 08:40:38 PDT."
             <2E3FA0558747934A8F753CC533A3F6DF043C32B6@red-msg-24.redmond.corp.microsoft.com> 
Date: Thu, 17 Aug 2000 21:14:10 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>May I observe that, in attempting to specify a source address selection
>algorithm, the WG goes well beyond the traditional IETF role, which is to
>focus on interoperability issues, not implementations? I would expect such
>algorithms to evolve in time, as we learn more on the subject. I would also
>expect them to vary a lot depending on how much a particular station knows
>about its environment, how far in the future it can predict the
>application's behavior, what arbitration is made between privacy and
>performance, etc. Rather than specify an actual algorithm, the WG should be
>content with a list of recommendations, in the form of "if you do this,
>expect that" or "don't do X, because it will cause interoperability problem
>Y." 

I strongly strongly agree with Christian.

regards,
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 18 15:00:36 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7ILwqq11969
	for ipng-dist; Fri, 18 Aug 2000 14:58:52 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7ILwg611959
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 14:58:42 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25973
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 14:58:43 -0700 (PDT)
Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16683
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 14:58:39 -0700 (PDT)
Received: from trantor.ferrara.linux.it (151.20.136.18) by smtp1.libero.it; 18 Aug 2000 23:58:35 +0200
Received: by trantor.ferrara.linux.it (Postfix, from userid 501)
	id 66D4F4CB2E; Fri, 18 Aug 2000 14:31:43 +0200 (CEST)
Date: Fri, 18 Aug 2000 14:31:43 +0200
From: Mauro Tortonesi <mauro@ferrara.linux.it>
To: ipng@sunroof.eng.sun.com
Subject: extension headers
Message-ID: <20000818143143.A833@trantor.ferrara.linux.it>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


i am writing an ipv6 enabled version of ping, and i want to dump informations 
collected from ipv6 packets returned by icmpv6 error messages.
the matter is: before i can collect informations from the tcp or udp header
i have to skip the ipv6 extension headers.

i have found some code which does exactly this in the linux kernel, with a 
different purpose. here is a note from alexei kuznetsov (linux kernel 
developer):

/*
 * Skip any extension headers. This is used by the ICMP module.
 *
 * Note that strictly speaking this conflicts with RFC1883 4.0:
 * ...The contents and semantics of each extension header determine whether 
 * or not to proceed to the next header.  Therefore, extension headers must
 * be processed strictly in the order they appear in the packet; a
 * receiver must not, for example, scan through a packet looking for a
 * particular kind of extension header and process that header prior to
 * processing all preceding ones.
 * 
 * We do exactly this. This is a protocol bug. We can't decide after a
 * seeing an unknown discard-with-error flavour TLV option if it's a 
 * ICMP error message or not (errors should never be send in reply to
 * ICMP error messages).
 * 
 * But I see no other way to do this. This might need to be reexamined
 * when Linux implements ESP (and maybe AUTH) headers.
 * --AK
 */

and this is what rfc2460 (section 4.0) says:

   ... to proceed to the next header.  Therefore, extension headers must
   be processed strictly in the order they appear in the packet; a
   receiver must not, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

it seems to me that there is at least one situation in which ipv6 
extension headers should be skipped - before a packet is sent back
within an icpmv6 error message, the kernel must be sure that it is not
an icmp error message.

i think there are many other situations in which low-level network programs 
need to access payload data without processing extension headers. the 
problems are two: 

	1) ipv6 standards do not seem to permit this	
	2) there is not a standard way to skip ext. headers

imho this wg should consider the following solutions:

	1) permit to programs the skip of the ext. headers IF AND ONLY IF
	they are only interested in collecting data for error reporting 
	purposes.
	2) provide a standard macro that returns protocol id of the upper 
	layer protocol and the offset of the payload from the beginning of 
	the packet, to be included in the next version of 
	draft-ietf-ipngwg-rfc2292bis.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			mauro@ferrara.linux.it
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 18 17:20:52 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7J0JRk12060
	for ipng-dist; Fri, 18 Aug 2000 17:19:27 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7J0JG612053
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 17:19:17 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA24051
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 17:19:10 -0700 (PDT)
Received: from roll.mentat.com (mentat.com [192.88.122.129])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA20019
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 17:19:11 -0700 (PDT)
Received: from leo.mentat.com (leo [192.88.122.132])
	by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA20298;
	Fri, 18 Aug 2000 17:19:19 -0700 (PDT)
Received: from feller.mentat.com (feller [192.88.122.144])
	by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA05140;
	Fri, 18 Aug 2000 17:19:19 -0700 (PDT)
Received: (from tim@localhost)
	by feller.mentat.com (8.9.3+Sun/8.9.3) id RAA08396;
	Fri, 18 Aug 2000 17:24:22 -0700 (PDT)
Date: Fri, 18 Aug 2000 17:24:22 -0700 (PDT)
From: Tim Hartrick <tim@mentat.com>
Message-Id: <200008190024.RAA08396@feller.mentat.com>
To: ipng@sunroof.eng.sun.com, mauro@ferrara.linux.it
Subject: Re: extension headers
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk




Mauro,

> 
> and this is what rfc2460 (section 4.0) says:
> 
>    ... to proceed to the next header.  Therefore, extension headers must
>    be processed strictly in the order they appear in the packet; a
>    receiver must not, for example, scan through a packet looking for a
>    particular kind of extension header and process that header prior to
>    processing all preceding ones.
> 
> it seems to me that there is at least one situation in which ipv6 
> extension headers should be skipped - before a packet is sent back
> within an icpmv6 error message, the kernel must be sure that it is not
> an icmp error message.
> 
> i think there are many other situations in which low-level network programs 
> need to access payload data without processing extension headers. the 
> problems are two: 
> 
> 	1) ipv6 standards do not seem to permit this	
> 	2) there is not a standard way to skip ext. headers
> 
> imho this wg should consider the following solutions:
> 
> 	1) permit to programs the skip of the ext. headers IF AND ONLY IF
> 	they are only interested in collecting data for error reporting 
> 	purposes.
> 	2) provide a standard macro that returns protocol id of the upper 
> 	layer protocol and the offset of the payload from the beginning of 
> 	the packet, to be included in the next version of 
> 	draft-ietf-ipngwg-rfc2292bis.
> 

I think that you are interpreting the text in RFC2460 too literally.
It was never the intension of that text to prevent kernel or application
code from fast forwarding through malformed extension headers in order
to determine if it was legal to send an ICMPv6 error or not.  It absolutely
wasn't intended to prevent an application or kernel from fast forwarding
through extension headers in datagrams that were returned as part of
the offending datagram in an ICMPv6 error message.

The intention was to guarantee that the headers would be processed in order
during the initial processing of the datagram.  If an error is detected
along the way there is nothing that prevents you from fast-forwarding
through the rest of the broken header(s) to check the contents of the terminal
header in the datagram.  Once an error is detected nothing else in the
datagram should be processed.

I don't think that we need to change anything in 2460 to make this clear(er).



Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 18 17:48:12 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7J0kql12096
	for ipng-dist; Fri, 18 Aug 2000 17:46:52 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7J0kf612089
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 17:46:41 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA15529
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 17:46:40 -0700 (PDT)
Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07562
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 17:46:40 -0700 (PDT)
Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1])
	by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA05145;
	Sat, 19 Aug 2000 09:46:22 +0900 (JST)
To: Mauro Tortonesi <mauro@ferrara.linux.it>
cc: ipng@sunroof.eng.sun.com
In-reply-to: mauro's message of Fri, 18 Aug 2000 14:31:43 +0200.
      <20000818143143.A833@trantor.ferrara.linux.it>
X-Template-Reply-To: itojun@itojun.org
X-Template-Return-Receipt-To: itojun@itojun.org
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
Subject: Re: extension headers
From: itojun@iijlab.net
Date: Sat, 19 Aug 2000 09:46:21 +0900
Message-ID: <5143.966645981@coconut.itojun.org>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


>i am writing an ipv6 enabled version of ping, and i want to dump informations 
>collected from ipv6 packets returned by icmpv6 error messages.
>the matter is: before i can collect informations from the tcp or udp header
>i have to skip the ipv6 extension headers.
>
>i have found some code which does exactly this in the linux kernel, with a 
>different purpose. here is a note from alexei kuznetsov (linux kernel 
>developer):

	please take a look at RFC2292.  IPv6 raw socket will not send you
	the IPv6 header nor extension header, it only sends up the real
	payload.  you will be able to grab information about IPv6 header and 
	extension header, via ancillary data stream.

	so, userland appliation (like your ping6) do not need to worry about
	extension header, normally.  if you would like to take a look at,
	you can always look at it via ancillary data stream.

	I believe there are IPv6-ready Linux ping6 packages, you may want to
	take a look at those.

itojun
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 18 19:28:19 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7J2QGj12145
	for ipng-dist; Fri, 18 Aug 2000 19:26:16 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7J2Q7612138
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 19:26:07 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA07910
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 19:26:02 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21492
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 19:26:02 -0700 (PDT)
Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id LAA15734;
	Sat, 19 Aug 2000 11:11:47 +0900 (JST)
Date: Sat, 19 Aug 2000 11:21:14 +0900
Message-ID: <y7v1yzmkn39.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: itojun@iijlab.net
Cc: mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com
Subject: Re: extension headers
In-Reply-To: In your message of "Sat, 19 Aug 2000 09:46:21 +0900"
	 <5143.966645981@coconut.itojun.org>
References: <20000818143143.A833@trantor.ferrara.linux.it>
	 <5143.966645981@coconut.itojun.org>
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 37
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>>>>> On Sat, 19 Aug 2000 09:46:21 +0900, 
>>>>> itojun@iijlab.net said:

>> i am writing an ipv6 enabled version of ping, and i want to dump informations 
>> collected from ipv6 packets returned by icmpv6 error messages.
>> the matter is: before i can collect informations from the tcp or udp header
>> i have to skip the ipv6 extension headers.
>> 
>> i have found some code which does exactly this in the linux kernel, with a 
>> different purpose. here is a note from alexei kuznetsov (linux kernel 
>> developer):

> 	please take a look at RFC2292.  IPv6 raw socket will not send you
> 	the IPv6 header nor extension header, it only sends up the real
> 	payload.  you will be able to grab information about IPv6 header and 
> 	extension header, via ancillary data stream.

> 	so, userland appliation (like your ping6) do not need to worry about
> 	extension header, normally.  if you would like to take a look at,
> 	you can always look at it via ancillary data stream.

I guess the intention of the original message is parsing the inner
IPv6 packet (including extension headers) within an ICMPv6 error
message. The advanced API does not strip such extension headers, so
application programs have to parse and strip the headers by
themselves.

Actually, we have code for this purpose in KAME's ping6 command (see
the pr_retip() function in ping6.c).

BTW: as for the specification, I agree with Tim; it is already clear
enough and we don't have to revise it.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 18 21:02:55 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7J41Y512208
	for ipng-dist; Fri, 18 Aug 2000 21:01:34 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7J41O612201
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 21:01:24 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA12941
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 21:01:22 -0700 (PDT)
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02953
	for <ipng@sunroof.eng.sun.com>; Fri, 18 Aug 2000 21:01:22 -0700 (PDT)
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id NAA07044;
	Sat, 19 Aug 2000 13:00:55 +0900
To: maruo@ferrara.linux.it
CC: ipng@sunroof.eng.sun.com
Subject: Re: extension headers
From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
 <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <y7v1yzmkn39.wl@condor.isl.rdc.toshiba.co.jp>
References: <20000818143143.A833@trantor.ferrara.linux.it>
	<5143.966645981@coconut.itojun.org>
	<y7v1yzmkn39.wl@condor.isl.rdc.toshiba.co.jp>
X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI)
X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Message-Id: <20000819130055B.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date: Sat, 19 Aug 2000 13:00:55 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 12
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

In article <y7v1yzmkn39.wl@condor.isl.rdc.toshiba.co.jp> (at Sat, 19 Aug 2000 11:21:14 +0900), JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp> says:

> Actually, we have code for this purpose in KAME's ping6 command (see
> the pr_retip() function in ping6.c).

FYI: I've brought it into Linux iputils ping6.
<http://apps.v6.linux.or.jp/usagi/apps/iputils/iputils-ss991024-usagi-20000819.patch.gz>

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Aug 19 05:02:14 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7JC0vh12368
	for ipng-dist; Sat, 19 Aug 2000 05:00:57 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7JC0k612360
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 05:00:47 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA20535
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 05:00:45 -0700 (PDT)
Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08316
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 05:00:44 -0700 (PDT)
Received: from trantor.ferrara.linux.it (151.20.137.208) by smtp2.libero.it; 19 Aug 2000 14:00:30 +0200
Received: by trantor.ferrara.linux.it (Postfix, from userid 501)
	id BBE384CE12; Sat, 19 Aug 2000 13:54:30 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by trantor.ferrara.linux.it (Postfix) with ESMTP
	id 69F954CE11; Sat, 19 Aug 2000 13:54:30 +0200 (CEST)
Date: Sat, 19 Aug 2000 13:54:30 +0200 (CEST)
From: Mauro Tortonesi <mauro@ferrara.linux.it>
To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp>
Cc: itojun@iijlab.net, IETF - IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: Re: extension headers
In-Reply-To: <y7v1yzmkn39.wl@condor.isl.rdc.toshiba.co.jp>
Message-ID: <Pine.LNX.4.21.0008191345450.896-100000@trantor.ferrara.linux.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Sat, 19 Aug 2000, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:

> >>>>> On Sat, 19 Aug 2000 09:46:21 +0900, 
> >>>>> itojun@iijlab.net said:
> 
> >> i am writing an ipv6 enabled version of ping, and i want to dump informations 
> >> collected from ipv6 packets returned by icmpv6 error messages.
> >> the matter is: before i can collect informations from the tcp or udp header
> >> i have to skip the ipv6 extension headers.
> >> 
> >> i have found some code which does exactly this in the linux kernel, with a 
> >> different purpose. here is a note from alexei kuznetsov (linux kernel 
> >> developer):
> 
> > 	please take a look at RFC2292.  IPv6 raw socket will not send you
> > 	the IPv6 header nor extension header, it only sends up the real
> > 	payload.  you will be able to grab information about IPv6 header and 
> > 	extension header, via ancillary data stream.
> 
> > 	so, userland appliation (like your ping6) do not need to worry about
> > 	extension header, normally.  if you would like to take a look at,
> > 	you can always look at it via ancillary data stream.
> 
> I guess the intention of the original message is parsing the inner
> IPv6 packet (including extension headers) within an ICMPv6 error
> message. The advanced API does not strip such extension headers, so
> application programs have to parse and strip the headers by
> themselves.

you have perfectly understood.

> Actually, we have code for this purpose in KAME's ping6 command (see
> the pr_retip() function in ping6.c).

i'll take a look at it. BTW can you explain to me why two different
programs? i think i have successfully integrated icmpv6 support into
netkit-base ping (you can get the patch on my site:
http://project6.ferrara.linux.it)

> BTW: as for the specification, I agree with Tim; it is already clear
> enough and we don't have to revise it.

this is probably the best choice. however what do you think about the
other proposal (the standard macro to skip ext. headers)?

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			mauro@ferrara.linux.it
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it

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

From owner-ipng@sunroof.eng.sun.com Sat Aug 19 05:27:56 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7JCQd812399
	for ipng-dist; Sat, 19 Aug 2000 05:26:39 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7JCQU612392
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 05:26:31 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA21198
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 05:26:31 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22990
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 06:26:30 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7JCQR653628;
	Sat, 19 Aug 2000 14:26:27 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA12193;
	Sat, 19 Aug 2000 14:26:27 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA69664;
	Sat, 19 Aug 2000 14:29:15 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008191229.OAA69664@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Mauro Tortonesi <mauro@ferrara.linux.it>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: extension headers 
In-reply-to: Your message of Fri, 18 Aug 2000 14:31:43 +0200.
             <20000818143143.A833@trantor.ferrara.linux.it> 
Date: Sat, 19 Aug 2000 14:29:15 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   it seems to me that there is at least one situation in which ipv6 
   extension headers should be skipped - before a packet is sent back
   within an icpmv6 error message, the kernel must be sure that it is not
   an icmp error message.
   
=> this was already discussed. The general idea was/is it doesn't matter
because it is expensive and in some cases impossible to verify the
offending packet is an icmp error message then if the trivial check
for an ICMP error fails then you may return an ICMPv6 error.
Just don't forget to apply the ICMPv6 rate limit on it...

   i think there are many other situations in which low-level network programs 
   need to access payload data without processing extension headers.

=> I don't understand how you may both access payload data and
no process extension headers because it is the processing of extension
headers which gives the position (and the kind) of payload data.
 Would you like to parse incomming packets twice, the first time in order
to find extension headers, the second time in order to process them?
An implementation may do this but this is not required... and this
couldn't work easily with ESP header.

   	2) provide a standard macro that returns protocol id of the upper 
   	layer protocol and the offset of the payload from the beginning of 
   	the packet, to be included in the next version of 
   	draft-ietf-ipngwg-rfc2292bis.
   
=> I disagree. What you want seems to be a wildcard raw socket and
this is not a standard feature for many good reasons. If you need
to look at inside incoming packets before their processing then
something like BPF is a better solution.

Regards

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Aug 19 11:48:54 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7JIlax12475
	for ipng-dist; Sat, 19 Aug 2000 11:47:36 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7JIlR612468
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 11:47:28 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA05080
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 11:47:27 -0700 (PDT)
Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23057
	for <ipng@sunroof.eng.sun.com>; Sat, 19 Aug 2000 11:47:26 -0700 (PDT)
Received: from trantor.ferrara.linux.it (151.20.157.130) by smtp2.libero.it; 19 Aug 2000 20:47:12 +0200
Received: by trantor.ferrara.linux.it (Postfix, from userid 501)
	id 105544CE52; Sat, 19 Aug 2000 15:31:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by trantor.ferrara.linux.it (Postfix) with ESMTP
	id 0BF2A4CB3E; Sat, 19 Aug 2000 15:31:13 +0200 (CEST)
Date: Sat, 19 Aug 2000 15:31:13 +0200 (CEST)
From: Mauro Tortonesi <mauro@ferrara.linux.it>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: IETF - IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: Re: extension headers 
In-Reply-To: <200008191229.OAA69664@givry.rennes.enst-bretagne.fr>
Message-ID: <Pine.LNX.4.21.0008191500590.1211-100000@trantor.ferrara.linux.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Sat, 19 Aug 2000, Francis Dupont wrote:

>  In your previous mail you wrote:
> 
>    it seems to me that there is at least one situation in which ipv6 
>    extension headers should be skipped - before a packet is sent back
>    within an icpmv6 error message, the kernel must be sure that it is not
>    an icmp error message.
>    
> => this was already discussed. The general idea was/is it doesn't matter
> because it is expensive and in some cases impossible to verify the
> offending packet is an icmp error message then if the trivial check
> for an ICMP error fails then you may return an ICMPv6 error.
> Just don't forget to apply the ICMPv6 rate limit on it...

right. 
 
>    i think there are many other situations in which low-level network programs 
>    need to access payload data without processing extension headers.
> 
> => I don't understand how you may both access payload data and
> no process extension headers because it is the processing of extension
> headers which gives the position (and the kind) of payload data.
>  Would you like to parse incomming packets twice, the first time in order
> to find extension headers, the second time in order to process them?

of course not. but think of ipv6 packets returned from an icmpv6 error
that don't have an esp. a direct access to the payload could fasten the
process of dumping the upper level protocol header.

> An implementation may do this but this is not required... and this
> couldn't work easily with ESP header.

in fact esp would be a serious problem. i had missed this point.

>    	2) provide a standard macro that returns protocol id of the upper 
>    	layer protocol and the offset of the payload from the beginning of 
>    	the packet, to be included in the next version of 
>    	draft-ietf-ipngwg-rfc2292bis.
>
> => I disagree. What you want seems to be a wildcard raw socket and
> this is not a standard feature for many good reasons. If you need
> to look at inside incoming packets before their processing then
> something like BPF is a better solution.

i don't want that. but think of ipv6 packets retured from icpmv6 error.
shouldn't be nice if dumping of the upper level protocol informations
could be done like this:

void dump_tcp(struct tcphdr *);

void dump(struct ip6_hdr *hdr)
{
	int offset, upper_level_protocol;
	uint8_t *payload;
	

	MY_FUNC(hdr, &offset, &upper_level_protocol);
	payload = ((uint8_t *)hdr) + offset;

	switch(upper_level_protocol) {
	case IPPROTO_TCP: dump_tcp((struct tcphdr*)payload);
			  break;
	case IPPROTO_UDP: ... etc,etc ...
	}
}

however, as you state, MY_FUNC would have great problems handling esp, and
that makes MY_FUNC nearly useless.

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			mauro@ferrara.linux.it
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it

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

From owner-ipng@sunroof.eng.sun.com Mon Aug 21 00:27:12 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7L7PtU12957
	for ipng-dist; Mon, 21 Aug 2000 00:25:55 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7L7Pk612950
	for <ipng@sunroof.eng.sun.com>; Mon, 21 Aug 2000 00:25:46 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA10600
	for <ipng@sunroof.eng.sun.com>; Mon, 21 Aug 2000 00:25:45 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29237
	for <ipng@sunroof.eng.sun.com>; Mon, 21 Aug 2000 00:25:42 -0700 (PDT)
Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA24572;
	Mon, 21 Aug 2000 16:10:51 +0900 (JST)
Date: Mon, 21 Aug 2000 16:20:05 +0900
Message-ID: <y7vhf8frsgq.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: mauro@ferrara.linux.it
Cc: ipng@sunroof.eng.sun.com
Subject: Re: extension headers
In-Reply-To: In your message of "Sat, 19 Aug 2000 13:54:30 +0200 (CEST)"
	 <Pine.LNX.4.21.0008191345450.896-100000@trantor.ferrara.linux.it>
References: <y7v1yzmkn39.wl@condor.isl.rdc.toshiba.co.jp>
	 <Pine.LNX.4.21.0008191345450.896-100000@trantor.ferrara.linux.it>
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 32
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>>>>> On Sat, 19 Aug 2000 13:54:30 +0200 (CEST), 
>>>>> Mauro Tortonesi <mauro@ferrara.linux.it> said:

>> Actually, we have code for this purpose in KAME's ping6 command (see
>> the pr_retip() function in ping6.c).

> i'll take a look at it. BTW can you explain to me why two different
> programs? i think i have successfully integrated icmpv6 support into
> netkit-base ping (you can get the patch on my site:
> http://project6.ferrara.linux.it)

I'm not sure what you meant by "two different programs", but if it was
the reason why we separated ping6 from the IPv4 version of ping,
please see the following URL:

http://www.freebsd.org/cgi/query-pr.cgi?pr=20527

>> BTW: as for the specification, I agree with Tim; it is already clear
>> enough and we don't have to revise it.

> this is probably the best choice. however what do you think about the
> other proposal (the standard macro to skip ext. headers)?

Hmm...it MAY be useful in some cases, but I'm personally not in favor
of the idea, because we'd rarely need such a function in applications
(remember that normal extension headers are grabbed as ancillary data
via the advanced API).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug 21 14:02:35 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7LL0oC13236
	for ipng-dist; Mon, 21 Aug 2000 14:00:50 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7LL0e613229;
	Mon, 21 Aug 2000 14:00:42 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA19947;
	Mon, 21 Aug 2000 14:00:38 -0700 (PDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12322;
	Mon, 21 Aug 2000 14:00:31 -0700 (PDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 567143E27; Mon, 21 Aug 2000 16:00:31 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP
	id 8067311F4; Mon, 21 Aug 2000 16:00:30 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id QAA0000544911; Mon, 21 Aug 2000 16:58:32 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008212058.QAA0000544911@anw.zk3.dec.com>
To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com,
   dhcp-v6@bucknell.edu, members@ipv6forum.com, tech@ipv6forum.com
Cc: reinhard.scholl@etsi.fr
Subject: IPv6 ETSI Test Event Web Page Pointer
Date: Mon, 21 Aug 2000 16:58:32 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

  ** PLEASE DO NOT RESPOND TO THIS MAIL **

Hi Folks,

Even though UNH cannot participate in this test event our colleagues
under the guidance of Francis Dupont at ENST in France have come to the
aid of IPv6 developers (thank you ENST and Francis) and working with
Reihhard Scholl there will be an IPv6 test event Oct 2-6.

I believe this is a very important event and vendors should really try
to attend.  Plus it is in a nice place "French Riviera" not that there
won't be a lot of hard work done of course.  This is serious stuff folks
and 3GPP needs our support and this test event.  Please see the
following URL:

http://www.etsi.org/bake-off

regards and thanks for your support,
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug 22 05:58:46 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7MCvY313765
	for ipng-dist; Tue, 22 Aug 2000 05:57:34 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7MCua613743;
	Tue, 22 Aug 2000 05:56:36 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA05904;
	Tue, 22 Aug 2000 05:56:37 -0700 (PDT)
From: george.tsirtsis@bt.com
Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA19531;
	Tue, 22 Aug 2000 05:56:35 -0700 (PDT)
Received: from cbtlipnt02.btlabs.bt.co.uk by gollum (local) with ESMTP;
          Tue, 22 Aug 2000 13:57:15 +0100
Received: by cbtlipnt02.btlabs.bt.co.uk 
          with Internet Mail Service (5.5.2651.88) id <PTMLK736>;
          Tue, 22 Aug 2000 13:55:56 +0100
Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2078A5AB6@mbtlipnt02.btlabs.bt.co.uk>
To: ngtrans@sunroof.eng.sun.com
Cc: ipng@sunroof.eng.sun.com
Subject: Dual Stack Mobility + Use of MIPv6 CCoA
Date: Tue, 22 Aug 2000 13:52:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.88)
Content-Type: text/plain
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

All,

As promised, this draft shows how IPv4 based communications can be
supported by a dual stack mobile node that only supports Mobile IPv6
(MIPv6). The aim is to use MIPv6 for mobility services while the
Mobile can still use its dual stack capabilities for IPv4
communications without the need for translation.

This draft is also relevant to recent discussions on the IPng list regarding
use of CCoA as source address in Mobile IPv6 Spec. In the draft we use the
MIPv6 CCoA to request an IPv4 address from the local DHCPv6 server (ala
DSTM).

Regards
George


> -----Original Message-----
> From:	Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org]
> Sent:	Tuesday, August 22, 2000 12:08 PM
> To:	IETF-Announce
> Subject:	I-D ACTION:draft-tsirtsis-v4-over-mipv6-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: IPv4 over Mobile IPv6 for Dual Stack nodes
> 	Author(s)	: G. Tsirtsis, A. O'Neill, S. Corson
> 	Filename	: draft-tsirtsis-v4-over-mipv6-00.txt
> 	Pages		: 4
> 	Date		: 21-Aug-00
> 	
> In this document we show how IPv4 based communications can be
> supported by a dual stack mobile node that only supports Mobile IPv6
> (MIPv6). The aim is to use MIPv6 for mobility services while the
> Mobile can still use its dual stack capabilities for IPv4
> communications without the need for translation.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-tsirtsis-v4-over-mipv6-00.txt
> 
> 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-tsirtsis-v4-over-mipv6-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:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-tsirtsis-v4-over-mipv6-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.
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug 22 12:36:33 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7MJYtG13994
	for ipng-dist; Tue, 22 Aug 2000 12:34:55 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7MJYk613987
	for <ipng@sunroof.eng.sun.com>; Tue, 22 Aug 2000 12:34:46 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA04706
	for <ipng@sunroof.eng.sun.com>; Tue, 22 Aug 2000 12:34:44 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.69.72.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07521
	for <ipng@sunroof.eng.sun.com>; Tue, 22 Aug 2000 12:34:43 -0700 (PDT)
Received: from mobilebeatles (dhcp87.docomo-usa.com [216.69.72.87])
	by fridge.docomo-usa.com (Postfix) with SMTP id 07F751C04
	for <ipng@sunroof.eng.sun.com>; Tue, 22 Aug 2000 12:34:38 -0700 (PDT)
Message-ID: <000801c00c6f$964e7040$574845d8@docomousa.com>
Reply-To: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>
From: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>
To: <ipng@sunroof.eng.sun.com>
Subject: IPv6 Source Routing
Date: Tue, 22 Aug 2000 12:31:36 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C00C34.E9A4D3A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C00C34.E9A4D3A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have some unclarity in IPv6 Source Route option. So, I decide to =
comment to this list for help.

In IPv6, routing header with n addresses will do the source route =
functionality. What will be the usual=20
process to get intermediate addresses that may fill Address[1] ... =
Address[n] field in IPv6 routing header?
In other words, does IPv6 provide functions that dynamically obtain =
intermediate nodes (for strict/loose=20
source route) in case of one node sending IPv6 packets to another using =
IPv6 source routing?

Also, is IPv6 in charge of explicitly listing such intermediate nodes in =
source routing? If so, how?

Any comments from IPv6 source routing and routing header knowledgeable =
person should be very helpful=20
for my purpose.  You can send your comment privately to me in case of =
ipng subscribers feeling bothered=20
by uninterested topic.

Thank you very much,

Youngjune Gwon
Research Engineer
NTT DoCoMo USA Research Labs

------=_NextPart_000_0005_01C00C34.E9A4D3A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I have some unclarity in IPv6 Source =
Route option.=20
So, I decide to comment to this list for help.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In IPv6, routing header with n =
addresses will do=20
the source route functionality.&nbsp;What will be the usual =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>process to get intermediate addresses =
that may fill=20
Address[1] ... Address[n] field in IPv6 routing header?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>In other words, does IPv6 provide =
functions that=20
dynamically obtain intermediate nodes (for strict/loose </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>source route) in case of one node =
sending IPv6=20
packets to another using IPv6 source routing?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Also, is IPv6 in charge of explicitly =
listing such=20
intermediate nodes in source routing? If so, how?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any comments from IPv6 source routing =
and routing=20
header knowledgeable person should be very helpful </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>for my purpose.&nbsp; You can send your =
comment=20
privately to me in case of ipng subscribers feeling bothered =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>by uninterested topic.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you very much,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Youngjune Gwon</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Research Engineer</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>NTT DoCoMo USA Research=20
Labs</FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01C00C34.E9A4D3A0--

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

From owner-ipng@sunroof.eng.sun.com Wed Aug 23 15:20:31 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7NMIor14628
	for ipng-dist; Wed, 23 Aug 2000 15:18:50 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7NMIf614621
	for <ipng@sunroof.eng.sun.com>; Wed, 23 Aug 2000 15:18:41 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20329
	for <ipng@sunroof.eng.sun.com>; Wed, 23 Aug 2000 15:18:42 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.69.72.10])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15076
	for <ipng@sunroof.eng.sun.com>; Wed, 23 Aug 2000 15:18:41 -0700 (PDT)
Received: from mobilebeatles (dhcp87.docomo-usa.com [216.69.72.87])
	by fridge.docomo-usa.com (Postfix) with SMTP id ED02A1C03
	for <ipng@sunroof.eng.sun.com>; Wed, 23 Aug 2000 15:18:40 -0700 (PDT)
Message-ID: <000801c00d4f$ab084fc0$574845d8@docomousa.com>
Reply-To: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>
From: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>
To: "ipng" <ipng@sunroof.eng.sun.com>
Subject: IPv6 Router
Date: Wed, 23 Aug 2000 15:15:38 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C00D14.FE9A3580"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C00D14.FE9A3580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Can anyone suggest how I can get IPv6 router? Is it available by any =
reliable vendor? If not, any suggestions?

Thanks

------=_NextPart_000_0005_01C00D14.FE9A3580
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Can anyone suggest how I can get IPv6 =
router? Is it=20
available by any reliable vendor? If not, any suggestions?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks</FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01C00D14.FE9A3580--

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

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 02:12:36 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7O9BIL15037
	for ipng-dist; Thu, 24 Aug 2000 02:11:18 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7O9B9615030;
	Thu, 24 Aug 2000 02:11:09 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA28902;
	Thu, 24 Aug 2000 02:11:08 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15777;
	Thu, 24 Aug 2000 03:11:06 -0600 (MDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7O9A8631245;
	Thu, 24 Aug 2000 11:10:09 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA06808;
	Thu, 24 Aug 2000 11:10:08 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA95355;
	Thu, 24 Aug 2000 11:10:34 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008240910.LAA95355@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: "Shiao-Li Charles Tsao" <sltsao@ccl.itri.org.tw>
cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com
Subject: Re: (ngtrans) Mobile IPv4/ Mobile IPv6 Interworking Issues 
In-reply-to: Your message of Thu, 24 Aug 2000 09:35:55 +0800.
             <00b501c00d6b$a5e7fd80$7d68608c@tsao> 
Date: Thu, 24 Aug 2000 11:10:34 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   The IPv4/IPv6 interworking problems seems to involve both Mobile IP and
   IPv4/IPv6 transition issues. We also have a draft which is relevant to
   this topic.

=> George's draft (draft-tsirtsis-v4-over-mipv6-00.txt) is very different,
he doesn't propose an integrated IPv4/IPv6 mobility but something very
simple (ie. trivial :-) based on two remarks:
 - new mobile phone infrastructures will be based on IPv6 (mainly because
   the lack of addresses in IPv4)
 - mobile phones will be dual stack hosts (because this is the safe way
   and this is not too expensive)
then a transition mechanism like DSTM which uses IPv4 over IPv6 tunnels
will be able to use freely/transparently all IPv6 devices like mobile IPv6
(I think George has EMA in mind but this applies too).

Regards

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 10:04:30 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7OH31I15276
	for ipng-dist; Thu, 24 Aug 2000 10:03:01 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7OH2u615269
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 10:02:56 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e7OH2ll06133
	for ipng@sunroof.eng.sun.com; Thu, 24 Aug 2000 10:02:47 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7O1ZA614754;
	Wed, 23 Aug 2000 18:35:10 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA23647;
	Wed, 23 Aug 2000 18:35:10 -0700 (PDT)
Received: from extmx.itri.org.tw (extmx.itri.org.tw [140.96.158.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29607;
	Wed, 23 Aug 2000 19:34:48 -0600 (MDT)
Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2])
	by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id JAA05755;
	Thu, 24 Aug 2000 09:37:52 +0800 (CST)
Received: from tsao (pc104125.ccl.itri.org.tw [140.96.104.125])
	by nti.itri.org.tw (8.8.8/8.8.8) with SMTP id JAA24419;
	Thu, 24 Aug 2000 09:35:35 +0800 (CST)
Message-ID: <00b501c00d6b$a5e7fd80$7d68608c@tsao>
From: "Shiao-Li Charles Tsao" <sltsao@ccl.itri.org.tw>
To: <ngtrans@sunroof.eng.sun.com>
Cc: <ipng@sunroof.eng.sun.com>
References: <5104D4DBC598D211B5FE0000F8FE7EB2078A5AB6@mbtlipnt02.btlabs.bt.co.uk>
Subject: Mobile IPv4/ Mobile IPv6 Interworking Issues
Date: Thu, 24 Aug 2000 09:35:55 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B2_01C00DAE.B3910470"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00B2_01C00DAE.B3910470
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear All,=20

Sorry for interrupting you.
The IPv4/IPv6 interworking problems seems to involve both Mobile IP and =
IPv4/IPv6 transition issues. We also have a draft which is relevant to =
this topic. The document specifies mechanisms to solve mobility problems =
in IPv4 and IPv6 interconnected networks for IPv4 or IPv6 mobile nodes. =
The solution adopts dual stack model that implements a new address =
mapper on mobile nodes. The dual stack model with the address mapper can =
facilicate the mobility services for IPv4 or IPv6 mobile nodes in =
between IPv4 and IPv6 networks. You can get it from the following URL, =
if you are interested in it
http://www.ietf.org/internet-drafts/draft-tsao-mobileip-duelstack-model-0=
0.txt

I appreciate your suggestions and comments. Thank you.

Best Regards,

Shiao-Li Tsao




----- Original Message -----=20
From: <george.tsirtsis@bt.com>
To: <ngtrans@sunroof.eng.sun.com>
Cc: <ipng@sunroof.eng.sun.com>
Sent: Tuesday, August 22, 2000 8:52 PM
Subject: (ngtrans) Dual Stack Mobility + Use of MIPv6 CCoA


> All,
>=20
> As promised, this draft shows how IPv4 based communications can be
> supported by a dual stack mobile node that only supports Mobile IPv6
> (MIPv6). The aim is to use MIPv6 for mobility services while the
> Mobile can still use its dual stack capabilities for IPv4
> communications without the need for translation.
>=20
> This draft is also relevant to recent discussions on the IPng list =
regarding
> use of CCoA as source address in Mobile IPv6 Spec. In the draft we use =
the
> MIPv6 CCoA to request an IPv4 address from the local DHCPv6 server =
(ala
> DSTM).
>=20
> Regards
> George
>=20
>=20
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [SMTP:Internet-Drafts@ietf.org]
> > Sent: Tuesday, August 22, 2000 12:08 PM
> > To: IETF-Announce
> > Subject: I-D ACTION:draft-tsirtsis-v4-over-mipv6-00.txt
> >=20
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >=20
> >=20
> > Title : IPv4 over Mobile IPv6 for Dual Stack nodes
> > Author(s) : G. Tsirtsis, A. O'Neill, S. Corson
> > Filename : draft-tsirtsis-v4-over-mipv6-00.txt
> > Pages : 4
> > Date : 21-Aug-00
> >=20
> > In this document we show how IPv4 based communications can be
> > supported by a dual stack mobile node that only supports Mobile IPv6
> > (MIPv6). The aim is to use MIPv6 for mobility services while the
> > Mobile can still use its dual stack capabilities for IPv4
> > communications without the need for translation.
> >=20
> > A URL for this Internet-Draft is:
> > =
http://www.ietf.org/internet-drafts/draft-tsirtsis-v4-over-mipv6-00.txt
> >=20
> > 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-tsirtsis-v4-over-mipv6-00.txt".
> >=20
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html=20
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> >=20
> > Internet-Drafts can also be obtained by e-mail.
> >=20
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-tsirtsis-v4-over-mipv6-00.txt".
> >=20
> > 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.
> >=20
> >=20
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.

------=_NextPart_000_00B2_01C00DAE.B3910470
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2>Dear All, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Sorry for interrupting =
you.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT face=3D"Courier New" =
size=3D2>The=20
IPv4/IPv6 interworking problems seems to involve both&nbsp;Mobile IP=20
and&nbsp;IPv4/IPv6 transition issues. </FONT></FONT><FONT =
face=3D"Courier New"=20
size=3D2>We&nbsp;also have a draft which is relevant to this=20
topic.&nbsp;The&nbsp;document specifies mechanisms to solve=20
mobility&nbsp;problems in IPv4 and IPv6 interconnected networks for IPv4 =
or IPv6=20
mobile nodes. The solution&nbsp;adopts dual stack model that implements =
a new=20
address mapper&nbsp;on mobile nodes. </FONT><FONT face=3D"Courier New" =
size=3D2>The=20
dual stack model with the address mapper can facilicate t</FONT><FONT=20
face=3D"Courier New" size=3D2>he mobility services for&nbsp;IPv4 or IPv6 =
mobile=20
nodes&nbsp;in between IPv4 and IPv6 networks. </FONT><FONT =
face=3D"Courier New"=20
size=3D2>You can get it from the following URL, if you are interested in =

it</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-tsao-mobileip-duelstack=
-model-00.txt">http://www.ietf.org/internet-drafts/draft-tsao-mobileip-du=
elstack-model-00.txt</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>I&nbsp;appreciate your =
suggestions and=20
comments. Thank you.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Best Regards,<BR></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Shiao-Li =
Tsao<BR><BR></DIV></FONT>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;</DIV></FONT>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>----- Original Message ----- =
</FONT>
<DIV><FONT face=3D"Courier New" size=3D2From: &lt;</FONT><A=20
href=3D"mailto:george.tsirtsis@bt.com"><FONT face=3D"Courier New"=20
size=3D2>george.tsirtsis@bt.com</FONT></A><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>To: &lt;</FONT><A=20
href=3D"mailto:ngtrans@sunroof.eng.sun.com"><FONT face=3D"Courier New"=20
size=3D2>ngtrans@sunroof.eng.sun.com</FONT></A><FONT face=3D"Courier =
New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:ipng@sunroof.eng.sun.com"><FONT face=3D"Courier New"=20
size=3D2>ipng@sunroof.eng.sun.com</FONT></A><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Sent: Tuesday, August 22, 2000 =
8:52=20
PM</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Subject: (ngtrans) Dual Stack =
Mobility +=20
Use of MIPv6 CCoA</FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3D"Courier New" size=3D2>&gt; All,<BR>&gt; =
<BR>&gt; As=20
promised, this draft shows how IPv4 based communications can be<BR>&gt;=20
supported by a dual stack mobile node that only supports Mobile =
IPv6<BR>&gt;=20
(MIPv6). The aim is to use MIPv6 for mobility services while the<BR>&gt; =
Mobile=20
can still use its dual stack capabilities for IPv4<BR>&gt; =
communications=20
without the need for translation.<BR>&gt; <BR>&gt; This draft is also =
relevant=20
to recent discussions on the IPng list regarding<BR>&gt; use of CCoA as =
source=20
address in Mobile IPv6 Spec. In the draft we use the<BR>&gt; MIPv6 CCoA =
to=20
request an IPv4 address from the local DHCPv6 server (ala<BR>&gt; =
DSTM).<BR>&gt;=20
<BR>&gt; Regards<BR>&gt; George<BR>&gt; <BR>&gt; <BR>&gt; &gt; =
-----Original=20
Message-----<BR>&gt; &gt; From: </FONT><A=20
href=3D"mailto:Internet-Drafts@ietf.org"><FONT face=3D"Courier New"=20
size=3D2>Internet-Drafts@ietf.org</FONT></A><FONT face=3D"Courier New" =
size=3D2>=20
[</FONT><A href=3D"mailto:SMTP:Internet-Drafts@ietf.org"><FONT =
face=3D"Courier New"=20
size=3D2>SMTP:Internet-Drafts@ietf.org</FONT></A><FONT face=3D"Courier =
New"=20
size=3D2>]<BR>&gt; &gt; Sent: Tuesday, August 22, 2000 12:08 PM<BR>&gt; =
&gt; To:=20
IETF-Announce<BR>&gt; &gt; Subject: I-D=20
ACTION:draft-tsirtsis-v4-over-mipv6-00.txt<BR>&gt; &gt; <BR>&gt; &gt; A =
New=20
Internet-Draft is available from the on-line Internet-Drafts<BR>&gt; =
&gt;=20
directories.<BR>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; Title : IPv4 over =
Mobile=20
IPv6 for Dual Stack nodes<BR>&gt; &gt; Author(s) : G. Tsirtsis, A. =
O'Neill, S.=20
Corson<BR>&gt; &gt; Filename : =
draft-tsirtsis-v4-over-mipv6-00.txt<BR>&gt; &gt;=20
Pages : 4<BR>&gt; &gt; Date : 21-Aug-00<BR>&gt; &gt; <BR>&gt; &gt; In =
this=20
document we show how IPv4 based communications can be<BR>&gt; &gt; =
supported by=20
a dual stack mobile node that only supports Mobile IPv6<BR>&gt; &gt; =
(MIPv6).=20
The aim is to use MIPv6 for mobility services while the<BR>&gt; &gt; =
Mobile can=20
still use its dual stack capabilities for IPv4<BR>&gt; &gt; =
communications=20
without the need for translation.<BR>&gt; &gt; <BR>&gt; &gt; A URL for =
this=20
Internet-Draft is:<BR>&gt; &gt; </FONT><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-tsirtsis-v4-over-mipv6-=
00.txt"><FONT=20
face=3D"Courier New"=20
size=3D2>http://www.ietf.org/internet-drafts/draft-tsirtsis-v4-over-mipv6=
-00.txt</FONT></A><BR><FONT=20
face=3D"Courier New" size=3D2>&gt; &gt; <BR>&gt; &gt; Internet-Drafts =
are also=20
available by anonymous FTP. Login with the<BR>&gt; &gt; username<BR>&gt; =
&gt;=20
"anonymous" and a password of your e-mail address. After logging =
in,<BR>&gt;=20
&gt; type "cd internet-drafts" and then<BR>&gt; &gt; "get=20
draft-tsirtsis-v4-over-mipv6-00.txt".<BR>&gt; &gt; <BR>&gt; &gt; A list =
of=20
Internet-Drafts directories can be found in<BR>&gt; &gt; </FONT><A=20
href=3D"http://www.ietf.org/shadow.html"><FONT face=3D"Courier New"=20
size=3D2>http://www.ietf.org/shadow.html</FONT></A><FONT face=3D"Courier =
New"=20
size=3D2> <BR>&gt; &gt; or </FONT><A=20
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt"><FONT face=3D"Courier =
New"=20
size=3D2>ftp://ftp.ietf.org/ietf/1shadow-sites.txt</FONT></A><BR><FONT=20
face=3D"Courier New" size=3D2>&gt; &gt; <BR>&gt; &gt; <BR>&gt; &gt; =
Internet-Drafts=20
can also be obtained by e-mail.<BR>&gt; &gt; <BR>&gt; &gt; Send a =
message=20
to:<BR>&gt; &gt; </FONT><A href=3D"mailto:mailserv@ietf.org"><FONT=20
face=3D"Courier New" size=3D2>mailserv@ietf.org</FONT></A><FONT =
face=3D"Courier New"=20
size=3D2>.<BR>&gt; &gt; In the body type:<BR>&gt; &gt; "FILE=20
/internet-drafts/draft-tsirtsis-v4-over-mipv6-00.txt".<BR>&gt; &gt; =
<BR>&gt;=20
&gt; NOTE: The mail server at ietf.org can return the document =
in<BR>&gt; &gt;=20
MIME-encoded form by using the "mpack" utility.&nbsp; To use =
this<BR>&gt; &gt;=20
feature, insert the command "ENCODING mime" before the "FILE"<BR>&gt; =
&gt;=20
command.&nbsp; To decode the response(s), you will need "munpack" =
or<BR>&gt;=20
&gt; a MIME-compliant mail reader.&nbsp; Different MIME-compliant mail=20
readers<BR>&gt; &gt; exhibit different behavior, especially when dealing =

with<BR>&gt; &gt; "multipart" MIME messages (i.e. documents which have =
been=20
split<BR>&gt; &gt; up into multiple messages), so check your local =
documentation=20
on<BR>&gt; &gt; how to manipulate these messages.<BR>&gt; &gt; <BR>&gt; =
&gt;=20
<BR>&gt; &gt; Below is the data which will enable a MIME compliant mail=20
reader<BR>&gt; &gt; implementation to automatically retrieve the ASCII =
version=20
of the<BR>&gt; &gt; Internet-Draft.</FONT></BODY></HTML>

------=_NextPart_000_00B2_01C00DAE.B3910470--


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

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 10:31:52 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7OHU4c15354
	for ipng-dist; Thu, 24 Aug 2000 10:30:04 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7OHTx615347
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 10:29:59 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e7OHToS06184
	for ipng@sunroof.eng.sun.com; Thu, 24 Aug 2000 10:29:50 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7OA24615121;
	Thu, 24 Aug 2000 03:02:04 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA11359;
	Thu, 24 Aug 2000 03:02:04 -0700 (PDT)
Received: from extmx.itri.org.tw (extmx.itri.org.tw [140.96.158.1])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19187;
	Thu, 24 Aug 2000 03:01:31 -0700 (PDT)
Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2])
	by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id SAA30997;
	Thu, 24 Aug 2000 18:04:00 +0800 (CST)
Received: from tsao (pc104125.ccl.itri.org.tw [140.96.104.125])
	by nti.itri.org.tw (8.8.8/8.8.8) with SMTP id SAA18067;
	Thu, 24 Aug 2000 18:01:38 +0800 (CST)
Message-ID: <009501c00db2$5aedfd60$7d68608c@tsao>
From: "Shiao-Li Charles Tsao" <sltsao@ccl.itri.org.tw>
To: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>
Cc: <ngtrans@sunroof.eng.sun.com>, <ipng@sunroof.eng.sun.com>
References: <200008240910.LAA95355@givry.rennes.enst-bretagne.fr>
Subject: Re: (ngtrans) Mobile IPv4/ Mobile IPv6 Interworking Issues 
Date: Thu, 24 Aug 2000 18:01:58 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0092_01C00DF5.659ADB50"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0092_01C00DF5.659ADB50
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Thanks for your comments.=20

Yes, George's draft is different from the Mobile IPv4/v6 Interworking =
proposal(draft-tsao-mobileip-duelstack-model-00.txt). However, these two =
drafts can be used to solve some of the mobility problems in IPv6/IPv4 =
interworking. That is why I pose the related draft on the mailing list.=20

Regards,
Shiao-Li


----- Original Message -----=20
From: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>
To: "Shiao-Li Charles Tsao" <sltsao@ccl.itri.org.tw>
Cc: <ngtrans@sunroof.eng.sun.com>; <ipng@sunroof.eng.sun.com>
Sent: Thursday, August 24, 2000 5:10 PM
Subject: Re: (ngtrans) Mobile IPv4/ Mobile IPv6 Interworking Issues=20


> In your previous mail you wrote:
>=20
>    The IPv4/IPv6 interworking problems seems to involve both Mobile IP =
and
>    IPv4/IPv6 transition issues. We also have a draft which is relevant =
to
>    this topic.
>=20
> =3D> George's draft (draft-tsirtsis-v4-over-mipv6-00.txt) is very =
different,
> he doesn't propose an integrated IPv4/IPv6 mobility but something very
> simple (ie. trivial :-) based on two remarks:
>  - new mobile phone infrastructures will be based on IPv6 (mainly =
because
>    the lack of addresses in IPv4)
>  - mobile phones will be dual stack hosts (because this is the safe =
way
>    and this is not too expensive)
> then a transition mechanism like DSTM which uses IPv4 over IPv6 =
tunnels
> will be able to use freely/transparently all IPv6 devices like mobile =
IPv6
> (I think George has EMA in mind but this applies too).
>=20
> Regards
>=20
> Francis.Dupont@enst-bretagne.fr

------=_NextPart_000_0092_01C00DF5.659ADB50
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2>Thanks for your comments. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Yes, George's draft =
is&nbsp;different from=20
the Mobile IPv4/v6 Interworking=20
proposal(draft-tsao-mobileip-duelstack-model-00.txt). However, these two =
drafts=20
can be used to solve&nbsp;some of the mobility problems in IPv6/IPv4=20
interworking.&nbsp;That is why I pose the related draft on the mailing =
list.=20
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Shiao-Li</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>----- Original Message ----- =
</FONT>
<DIV><FONT face=3D"Courier New" size=3D2From: "Francis Dupont" =
&lt;</FONT><A=20
href=3D"mailto:Francis.Dupont@enst-bretagne.fr"><FONT face=3D"Courier =
New"=20
size=3D2>Francis.Dupont@enst-bretagne.fr</FONT></A><FONT face=3D"Courier =
New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>To: "Shiao-Li Charles Tsao" =
&lt;</FONT><A=20
href=3D"mailto:sltsao@ccl.itri.org.tw"><FONT face=3D"Courier New"=20
size=3D2>sltsao@ccl.itri.org.tw</FONT></A><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Cc: &lt;</FONT><A=20
href=3D"mailto:ngtrans@sunroof.eng.sun.com"><FONT face=3D"Courier New"=20
size=3D2>ngtrans@sunroof.eng.sun.com</FONT></A><FONT face=3D"Courier =
New"=20
size=3D2>&gt;; &lt;</FONT><A =
href=3D"mailto:ipng@sunroof.eng.sun.com"><FONT=20
face=3D"Courier New" size=3D2>ipng@sunroof.eng.sun.com</FONT></A><FONT=20
face=3D"Courier New" size=3D2>&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Sent: Thursday, August 24, 2000 =
5:10=20
PM</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Subject: Re: (ngtrans) Mobile =
IPv4/ Mobile=20
IPv6 Interworking Issues </FONT></DIV></DIV>
<DIV><BR></DIV><FONT face=3D"Courier New" size=3D2>&gt; In your previous =
mail you=20
wrote:<BR>&gt; <BR>&gt; &nbsp;&nbsp; The IPv4/IPv6 interworking problems =
seems=20
to involve both Mobile IP and<BR>&gt; &nbsp;&nbsp; IPv4/IPv6 transition =
issues.=20
We also have a draft which is relevant to<BR>&gt; &nbsp;&nbsp; this=20
topic.<BR>&gt; <BR>&gt; =3D&gt; George's draft=20
(draft-tsirtsis-v4-over-mipv6-00.txt) is very different,<BR>&gt; he =
doesn't=20
propose an integrated IPv4/IPv6 mobility but something very<BR>&gt; =
simple (ie.=20
trivial :-) based on two remarks:<BR>&gt; &nbsp;- new mobile phone=20
infrastructures will be based on IPv6 (mainly because<BR>&gt; =
&nbsp;&nbsp; the=20
lack of addresses in IPv4)<BR>&gt; &nbsp;- mobile phones will be dual =
stack=20
hosts (because this is the safe way<BR>&gt; &nbsp;&nbsp; and this is not =
too=20
expensive)<BR>&gt; then a transition mechanism like DSTM which uses IPv4 =
over=20
IPv6 tunnels<BR>&gt; will be able to use freely/transparently all IPv6 =
devices=20
like mobile IPv6<BR>&gt; (I think George has EMA in mind but this =
applies=20
too).<BR>&gt; <BR>&gt; Regards<BR>&gt; <BR>&gt; </FONT><A=20
href=3D"mailto:Francis.Dupont@enst-bretagne.fr"><FONT face=3D"Courier =
New"=20
size=3D2>Francis.Dupont@enst-bretagne.fr</FONT></A></BODY></HTML>

------=_NextPart_000_0092_01C00DF5.659ADB50--


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

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 10:34:48 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7OHXVc15373
	for ipng-dist; Thu, 24 Aug 2000 10:33:32 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7OHXL615366
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 10:33:21 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA10758
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 10:33:20 -0700 (PDT)
Received: from zama.net (cust-zama.semaphore.net [209.221.132.90] (may be forged))
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15880
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 10:33:20 -0700 (PDT)
Received: from kopachuck (granite.zama.net [206.81.197.18] (may be forged))
	by zama.net (8.9.3/8.9.3) with SMTP id KAA18296;
	Thu, 24 Aug 2000 10:28:02 -0700 (PDT)
Message-ID: <008a01c00df1$8f2e27a0$b50c10ac@zama.net>
From: "Grant Furness" <grant@zama.net>
To: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>,
   "ipng" <ipng@sunroof.eng.sun.com>
References: <000801c00d4f$ab084fc0$574845d8@docomousa.com>
Subject: Re: IPv6 Router
Date: Thu, 24 Aug 2000 10:33:59 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0087_01C00DB6.D02B1FF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0087_01C00DB6.D02B1FF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Nortel/Bay Networks has IPv6 enabled through their product line in =
software.  Also, Hitachi has a production router running IPv6, but is =
available only in Asia.  You should also look at Ipsilon.

A free alternative, though, is to use FreeBSD, which works well in a =
non-production environment if you are just testing.  Copy the IPv6 =
options section from /etc/defaults/rc.conf into /etc/rc.conf.  You will =
need to make the following changes:
    ipv6_enable=3D"YES"
    ipv6_gateway_enable=3D"YES"
    ipv6_router_enable=3D"YES"

If you want the router to perform router advertisement for neighbor =
discovery, make the following changes:
    prefixcmd_enable=3D"YES"
    rtadvd_enable=3D"YES"
    ipv6_prefix_[int. name]=3D"your ipv6 prefix"

Let me know if you have any more questions.
  ----- Original Message -----=20
  From: Youngjune Lee Gwon=20
  To: ipng=20
  Sent: Wednesday, August 23, 2000 3:15 PM
  Subject: IPv6 Router


  Can anyone suggest how I can get IPv6 router? Is it available by any =
reliable vendor? If not, any suggestions?

  Thanks

------=_NextPart_000_0087_01C00DB6.D02B1FF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Nortel/Bay Networks has IPv6 enabled =
through their=20
product line in software.&nbsp; Also, Hitachi has a production router =
running=20
IPv6, but is available only in Asia.&nbsp; You should also look at=20
Ipsilon.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A free alternative, though, is to use =
FreeBSD,=20
which works well in a non-production environment if you are just =
testing.&nbsp;=20
Copy the IPv6 options section from /etc/defaults/rc.conf into=20
/etc/rc.conf.&nbsp; You will need to make the following =
changes:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
ipv6_enable=3D"YES"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
ipv6_gateway_enable=3D"YES"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
ipv6_router_enable=3D"YES"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If you want the router to perform =
router=20
advertisement for neighbor discovery, make the following =
changes:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;=20
prefixcmd_enable=3D"YES"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
rtadvd_enable=3D"YES"</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; ipv6_prefix_[int. =
name]=3D"your=20
ipv6 prefix"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Let me know if you have any more=20
questions.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:gyj@dcl.docomo-usa.com" =
title=3Dgyj@dcl.docomo-usa.com>Youngjune=20
  Lee Gwon</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:ipng@sunroof.eng.sun.com" =
title=3Dipng@sunroof.eng.sun.com>ipng</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, August 23, =
2000 3:15=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> IPv6 Router</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial size=3D2>Can anyone suggest how I can get IPv6 =
router? Is=20
  it available by any reliable vendor? If not, any =
suggestions?</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial =
size=3D2>Thanks</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0087_01C00DB6.D02B1FF0--

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

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 11:52:31 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7OIp3X15466
	for ipng-dist; Thu, 24 Aug 2000 11:51:03 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7OIos615459
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 11:50:54 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA02359
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 11:50:53 -0700 (PDT)
Received: from fridge.docomo-usa.com (fridge.docomo-usa.com [216.69.72.10])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07267
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 12:50:52 -0600 (MDT)
Received: from mobilebeatles (dhcp87.docomo-usa.com [216.69.72.87])
	by fridge.docomo-usa.com (Postfix) with SMTP id 20DFE1C02
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 11:50:51 -0700 (PDT)
Message-ID: <000801c00dfb$cf19c9a0$574845d8@docomousa.com>
Reply-To: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>
From: "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com>
To: "ipng" <ipng@sunroof.eng.sun.com>
Subject: IPv6 Source Route
Date: Thu, 24 Aug 2000 11:47:52 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01C00DC1.22AA28C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C00DC1.22AA28C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Anybody has any idea on IPv6 source route, yet? How do IPv6 node, or =
IPv6 Routers, obtain intermediate nodes' addresses
that may be filled in address[1] ... address[n] field in IPv6 routing =
header for strict/loose source route option?
Are there standard method of getting such information in IPv6 or other =
auxiliary protocols?

Any comment is welcomed.=20

Thank you


------=_NextPart_000_0005_01C00DC1.22AA28C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Anybody has any idea on IPv6 source =
route, yet? How=20
do IPv6 node, or IPv6 Routers, obtain intermediate nodes' =
addresses</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>that may be filled in address[1] ... =
address[n]=20
field in IPv6 routing header for strict/loose source route =
option?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Are there standard method of getting =
such=20
information in IPv6 or other auxiliary protocols?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any comment is welcomed. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0005_01C00DC1.22AA28C0--

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

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 20:27:27 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7P3Q4N15691
	for ipng-dist; Thu, 24 Aug 2000 20:26:04 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7P3Pr615684
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 20:25:54 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA15305
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 20:25:52 -0700 (PDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA18929
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 20:25:51 -0700 (PDT)
Received: from localhost (shuttle.sixyards.wide.toshiba.co.jp [3ffe:501:100f:0:200:f8ff:fe01:61cf])
	by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA12812;
	Fri, 25 Aug 2000 12:09:41 +0900 (JST)
Date: Fri, 25 Aug 2000 12:18:52 +0900
Message-ID: <y7vu2caqb8j.wl@condor.isl.rdc.toshiba.co.jp>
From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
 <jinmei@isl.rdc.toshiba.co.jp>
To: gyj@dcl.docomo-usa.com
Cc: ipng@sunroof.eng.sun.com
Subject: Re: IPv6 Source Routing
In-Reply-To: In your message of "Tue, 22 Aug 2000 12:31:36 -0700"
	 <000801c00c6f$964e7040$574845d8@docomousa.com>
References: <000801c00c6f$964e7040$574845d8@docomousa.com>
User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.6 Mule/4.0 (HANANOEN)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
X-Dispatcher: imput version 980905(IM100)
Lines: 26
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>>>>> On Tue, 22 Aug 2000 12:31:36 -0700, 
>>>>> "Youngjune Lee Gwon" <gyj@dcl.docomo-usa.com> said:

> I have some unclarity in IPv6 Source Route option. So, I decide to comment to this list for help.

> In IPv6, routing header with n addresses will do the source route functionality. What will be the usual 
> process to get intermediate addresses that may fill Address[1] ... Address[n] field in IPv6 routing header?

(I may misunderstand your question, but)
Basically, the sender (an application or an operator) should specify
all the intermediate nodes by hand.

> In other words, does IPv6 provide functions that dynamically obtain intermediate nodes (for strict/loose 
> source route) in case of one node sending IPv6 packets to another using IPv6 source routing?

No.

> Also, is IPv6 in charge of explicitly listing such intermediate
> nodes in source routing?

No.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 24 22:36:38 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7P5ZMa15722
	for ipng-dist; Thu, 24 Aug 2000 22:35:22 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7P5ZE615715
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 22:35:14 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA26119
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 22:35:12 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA21414
	for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 2000 22:35:13 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Aug 2000 22:35:12 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <QA2Z9NFZ>; Thu, 24 Aug 2000 22:35:12 -0700
Message-ID: <7695E2F6903F7A41961F8CF888D87EA83477CF@red-msg-06.redmond.corp.microsoft.com>
From: Richard Draves <richdr@microsoft.com>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group
	 <ipng@sunroof.eng.sun.com>
Subject: RE: When should mobile nodes use their care-of address, etc... 
Date: Thu, 24 Aug 2000 22:31:38 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> => the draft proposes a solution for application knowledge 
> (socket option)
> but not user knowledge (or do you suggest to add to every applications
> some arguments and code in order to control address 
> selections, I believe
> this is not your intent, then clearly your draft needs something...)

No, my belief is that few applications will find it necessary/desirable to
optimize their use in mobility situations and use a socket option to request
a care-of source address instead of a home address.

MIPv6 will avoid the dog-leg routing through the home agent in normal use,
when a mobile node initiates a connection using its home address. You
include the binding update in the first packet you send (eg, the TCP SYN) to
the correspondent. This is what the Lancaster implementation of mobility for
MSR IPv6 does.

So using the home address by default is really not that inefficient.

There is one detail here: we don't implement IKE (although we do implement
IPsec and will protect the mobility options with IPsec) and so I don't know
if the IKE negotiation of SAs to protect that first binding-update will
happen without going through the home agent. But this should be possible.

> PS: can you explain how the control is done in your implementation?
> PPS: perhaps an API for policy table control should be specified??

I don't see the need to standardize an API for policy table control. I view
the policy table in my draft as conceptual - implementations might have
various different ways of specifying policy. So it would be hard to
standardize APIs for controlling it.

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 03:45:11 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PAhnY15884
	for ipng-dist; Fri, 25 Aug 2000 03:43:49 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PAhd615877
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 03:43:39 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA23762
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 03:43:38 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28726
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:43:37 -0600 (MDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15325;
	Fri, 25 Aug 2000 06:43:38 -0400 (EDT)
Message-Id: <200008251043.GAA15325@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt
Date: Fri, 25 Aug 2000 06:43:38 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPNG Working Group of the IETF.

	Title		: IPv6 Multihoming with Route Aggregation
	Author(s)	: J. Yu
	Filename	: draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt
	Pages		: 7
	Date		: 24-Aug-00
	
With the growing requirements for reliable Internet connectivity,
increasing number of enterprises choose to acquire Internet
connectivity from more than one Internet Service Providers (ISPs) for
the purpose of connectivity redundancy and traffic load distribution.
The potential of large number of multi-connection sites impose direct
challenge on routing aggregation and consequently on scalability of
the global Internet routing. Hence a solution is highly desirable
which provides the benefit of multi-connection as well as the better
scalability of the global routing system. In addition, such solution
needs to be simple enough to be operationally manageable. With the
fast growth of ISP networks as well as enterprise networks, network
manageability is becoming an increasingly important requirement. This
document describes a solution which achieves the stated goals.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt

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-ipngwg-ipv6multihome-with-aggr-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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-ipv6multihome-with-aggr-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000824130048.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000824130048.I-D@ietf.org>

--OtherAccess--

--NextPart--


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

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 03:57:17 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PAtiZ15915
	for ipng-dist; Fri, 25 Aug 2000 03:55:44 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PAtZ615908
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 03:55:35 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA00888
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 03:55:34 -0700 (PDT)
Received: from ish7.ericsson.com.au ([203.61.155.111])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04158
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:55:32 -0600 (MDT)
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8])
	by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id UAA29369;
	Fri, 25 Aug 2000 20:53:10 +1000 (EST)
Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165])
	by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA13106;
	Fri, 25 Aug 2000 20:54:43 +1000 (EST)
Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21)
	id <RB097C0N>; Fri, 25 Aug 2000 20:54:40 +1000
Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB1C0@eaubrnt018.epa.ericsson.se>
From: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
To: "'Grant Furness'" <grant@zama.net>,
   Youngjune Lee Gwon
	 <gyj@dcl.docomo-usa.com>,
   ipng <ipng@sunroof.eng.sun.com>
Subject: RE: IPv6 Router
Date: Fri, 25 Aug 2000 20:54:36 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C00E82.DBF0C2A0"
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C00E82.DBF0C2A0
Content-Type: text/plain;
	charset="iso-8859-1"

Nortel/Bay Networks has IPv6 enabled through their product line in software.
Also, Hitachi has a production router running IPv6, but is available only in
Asia.  You should also look at Ipsilon. 
 
=> Also Ericsson Telebit has one, you should have a look there. It depends
on what you're 
after of course.


------_=_NextPart_001_01C00E82.DBF0C2A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">



<META content='"MSHTML 4.72.3616.1301"' name=GENERATOR>
<STYLE></STYLE>

</HEAD>
<BODY bgColor=#ffffff>
<BLOCKQUOTE>
    <DIV><FONT face=Arial size=2>Nortel/Bay Networks has IPv6 enabled through 
    their product line in software.&nbsp; Also, Hitachi has a production router 
    running IPv6, but is available only in Asia.&nbsp; You should also look at 
    Ipsilon.<SPAN class=700455110-25082000><FONT color=#0000ff face=Arial 
    size=2>&nbsp;</FONT></SPAN></FONT></DIV>
    <DIV><FONT face=Arial size=2><SPAN class=700455110-25082000><FONT 
    color=#0000ff face=Arial size=2></FONT></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=Arial size=2><SPAN class=700455110-25082000><FONT 
    color=#0000ff face=Arial size=2>=&gt; Also Ericsson Telebit has one, you 
    should have a look there. It depends on what 
    you're&nbsp;</FONT></SPAN></FONT></DIV>
    <DIV><FONT face=Arial size=2><SPAN class=700455110-25082000><FONT 
    color=#0000ff face=Arial size=2>after of 
course.</FONT></SPAN></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C00E82.DBF0C2A0--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 04:03:37 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PB2fJ15942
	for ipng-dist; Fri, 25 Aug 2000 04:02:41 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PB2X615935
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:02:33 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA20283
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:02:29 -0700 (PDT)
From: Nagi.Mahalingam@nokia.com
Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29415
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:02:28 -0700 (PDT)
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id <Q1R5TV2M>; Fri, 25 Aug 2000 14:02:03 +0300
Message-ID: <1D1620A986E0D21184210008C7089AEA5A5BF0@hueis02nok>
To: Hesham.Soliman@ericsson.com.au, grant@zama.net, gyj@dcl.docomo-usa.com,
   ipng@sunroof.eng.sun.com
Subject: RE: IPv6 Router
Date: Fri, 25 Aug 2000 14:02:01 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Yes, Ipsilon, now is part of Nokia ??
Nortel Networks certainly does - I am sure of that. 

-----Original Message-----
From: EXT Hesham Soliman (EPA) [mailto:Hesham.Soliman@ericsson.com.au]
Sent: 25 August 2000 11:55
To: 'Grant Furness'; Youngjune Lee Gwon; ipng
Subject: RE: IPv6 Router



Nortel/Bay Networks has IPv6 enabled through their product line in software.
Also, Hitachi has a production router running IPv6, but is available only in
Asia.  You should also look at Ipsilon. 
 
=> Also Ericsson Telebit has one, you should have a look there. It depends
on what you're 
after of course.

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

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 04:05:53 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PB50r15988
	for ipng-dist; Fri, 25 Aug 2000 04:05:00 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PB4p615981
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:04:51 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA01931
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:04:50 -0700 (PDT)
Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28029
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 04:04:50 -0700 (PDT)
Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135])
	by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA00201;
	Fri, 25 Aug 2000 12:04:48 +0100 (BST)
Received: from penelope (penelope [152.78.68.135])
	by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id MAA06907;
	Fri, 25 Aug 2000 12:04:47 +0100 (BST)
Date: Fri, 25 Aug 2000 12:04:47 +0100 (BST)
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: "Hesham Soliman (EPA)" <Hesham.Soliman@ericsson.com.au>
cc: "'Grant Furness'" <grant@zama.net>,
   Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>,
   ipng <ipng@sunroof.eng.sun.com>
Subject: RE: IPv6 Router
In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A5089EB1C0@eaubrnt018.epa.ericsson.se>
Message-ID: <Pine.SOL.4.20.0008251200460.2292-100000@penelope.ecs.soton.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

On Fri, 25 Aug 2000, Hesham Soliman (EPA) wrote:

> Nortel/Bay Networks has IPv6 enabled through their product line in software.
> Also, Hitachi has a production router running IPv6, but is available only in
> Asia.  You should also look at Ipsilon. 
>  
> => Also Ericsson Telebit has one, you should have a look there. It depends
> on what you're 
> after of course.

There is a list of router (and host) implementations at 
http://www.ipv6forum.com under the Implementations section.

If there's any missing or any new URLs to add, drop me a line.

tim

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

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 05:58:16 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PCuqs16051
	for ipng-dist; Fri, 25 Aug 2000 05:56:52 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PCuh616044
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 05:56:43 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA24599
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 05:56:44 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05341
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 05:56:42 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7PCuO620786;
	Fri, 25 Aug 2000 14:56:24 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA18581;
	Fri, 25 Aug 2000 14:56:09 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA00618;
	Fri, 25 Aug 2000 14:56:37 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008251256.OAA00618@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Richard Draves <richdr@microsoft.com>
cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: Re: When should mobile nodes use their care-of address, etc... 
In-reply-to: Your message of Thu, 24 Aug 2000 22:31:38 PDT.
             <7695E2F6903F7A41961F8CF888D87EA83477CF@red-msg-06.redmond.corp.microsoft.com> 
Date: Fri, 25 Aug 2000 14:56:37 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   > => the draft proposes a solution for application knowledge 
   > (socket option)
   > but not user knowledge (or do you suggest to add to every applications
   > some arguments and code in order to control address 
   > selections, I believe
   > this is not your intent, then clearly your draft needs something...)
   
   No, my belief is that few applications will find it necessary/desirable to
   optimize their use in mobility situations and use a socket option to request
   a care-of source address instead of a home address.
   
=> I disagree, there are some usages of mobility where random applications
should use a care-of address if it is closed enough to the destination,
and some where its depends on both the application and the proximity.
Your proposal is simply too inflexible and I don't understand why
we can get a policy per user, environment, ... and not a flag.

   MIPv6 will avoid the dog-leg routing through the home agent in normal use,
   when a mobile node initiates a connection using its home address. You
   include the binding update in the first packet you send (eg, the TCP SYN) to
   the correspondent. This is what the Lancaster implementation of mobility for
   MSR IPv6 does.
   
=> this has just a very little drawback, you assume there is already a
security association settled before by the totaly user-friendly and efficient
tool named IKE (:-)... I'd like to see what the Lancaster implementation
will do now with the (mandatory) security.

   So using the home address by default is really not that inefficient.
   
=> it is always inefficient and some times unnecessary. Mobility
is supposed to be one of the bug advantages of IPv6, don't restrict it
to some contexts please.

   There is one detail here: we don't implement IKE (although we do implement
   IPsec and will protect the mobility options with IPsec) and so I don't know
   if the IKE negotiation of SAs to protect that first binding-update will
   happen without going through the home agent. But this should be possible.

=> I have both IKE and mobility working together then I can answer.
IKE should use the care-of address and MUST use it for the first home
registration when the mobile is booted in visit. But IKE is a special
application (it has similar constraints for IPsec processing) then
what IKE needs a getsockname() clone which returns the care-of address
in place of the official (== home) address bound to the socket, ie.
this new socket option should simulate the mobility processing (ie.
the addition of an home address option, ...). It is easy to implement
and is enough if IKE computes its source address by a connect(peer)
followed by getsockname(), ie. the standard way to do it.

   > PS: can you explain how the control is done in your implementation?
   > PPS: perhaps an API for policy table control should be specified??
   
   I don't see the need to standardize an API for policy table control.

=> I agree but I don't know if I am going to change my opinion about this
in a new future. At least it should be well documented (then my first
question).

   I view the policy table in my draft as conceptual - implementations
   might have various different ways of specifying policy. So it would be
   hard to standardize APIs for controlling it.
   
=> again in general I prefer freedom to overspecification. My concern is
I have not concrete example to see if this position is reasonnable or
will lead to major interoperability problems.

Thanks

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 12:18:32 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PJF0C16256
	for ipng-dist; Fri, 25 Aug 2000 12:15:00 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PJEn616248
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 12:14:49 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA15563
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 12:14:48 -0700 (PDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13262
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 12:14:48 -0700 (PDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA43060;
	Fri, 25 Aug 2000 15:14:34 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA21924;
	Fri, 25 Aug 2000 15:14:34 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA24090; Fri, 25 Aug 2000 15:13:50 -0400
Message-Id: <200008251913.PAA24090@rotala.raleigh.ibm.com>
To: Jim Bound <bound@zk3.dec.com>
cc: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "Privacy Extensions for Stateless Address Autoconfiguration in IPv6s" 
In-Reply-To: Message from Jim Bound <bound@zk3.dec.com> 
   of "Mon, 07 Aug 2000 23:59:16 EDT." <200008080359.XAA0000024737@yquarry.zk3.dec.com> 
Date: Fri, 25 Aug 2000 15:13:50 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This didn't seem to actually make it out the first time.

From: Thomas Narten <narten@localhost.localdomain>
To: Jim Bound <bound@zk3.dec.com>
cc: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
Date: Wed, 09 Aug 2000 14:01:33 -0400
Subject: Re: W.G. Last Call on "Privacy Extensions for Stateless Address Autoconfiguration in IPv6s" 

Jim,

> >4.  Implications of Changing Interface Identifiers
> >
> >   The IPv6 addressing architecture goes to great lengths to ensure that
> >  interface identifiers are globally unique. During the IPng
> >   discussions of the GSE proposal [GSE], it was felt that keeping
> >   interface identifiers globally unique in practice might prove useful
> >  to future transport protocols. Usage of the algorithms in this
> >   document would eliminate that future flexibility.

> Can we get more words that this spec does not eliminate users who want
> to use identifiers that are globally unique by ignoring this entire
> spec?

I'm not sure what more you want the document to say. Can you be more
specific? Here is my reasoning. I think it is true that if anonymous
addresses become widely used in practice, the fact will be that a
large proportion of addresses will not have globally unique
identifiers in interface identifier part of an address. It may well be
that future uses of globally unique interface identifiers only makes
sense if the vast majority of addresses do have a globally unique
component. I.e, will such a scheme even be useful if only 80% of the
addresses have unique interface identifiers? What if the percentage is
only 50%?

> Also I waited to respond cause I asked 3 sys admins of very large
> networks to tell me if they would shut this off on an IPv6
> implementation.  All said yes and it appears the IETF had to play
> some poltics here.  This is just plain silly for corporate
> Intranets.

I tend to agree that anonymous addresses may not be appropriate in
some environments. One of the issues you are really getting at is
where the knobs to control useage of anonymous addresses should be. I
think a case can be made that the site should be able to disable their
usage (i.e, it may be corporate policy to do this). Should an end user
have the ability to override such a policy? In a corporate setting,
the answer is quite possibly no. But if a user is at home, and the
policy is set by the ISP, what then?

> Hence, I suggest that some words be stated that for corproate Intranet
> traffic this is may be very unnecessary.

How about I add the following lines to paragraph 2 in Section 4.:

>    The desires of protecting individual privacy vs. the desire to
>    effectively maintain and debug a network can conflict with each
>    other. Having clients use addresses that change over time will make
>    it more difficult to track down and isolate operational problems. For
>    example, when looking at packet traces, it could become more
>    difficult to determine whether one is seeing behavior caused by a
>    single errant machine, or by a number of them.

new line:

     Consequently, system administrators in environments where privacy
     is not a primary concern (e.g., corporate intranets) may choose
     to prohibit the assignment and usage of anonymous addresses on
     the nodes that it manages.


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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 12:27:13 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PJQAQ16283
	for ipng-dist; Fri, 25 Aug 2000 12:26:10 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PJQ1616276
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 12:26:01 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA21807
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 12:26:01 -0700 (PDT)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11245;
	Fri, 25 Aug 2000 12:26:00 -0700 (PDT)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA35686;
	Fri, 25 Aug 2000 15:25:57 -0400
Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA20182;
	Fri, 25 Aug 2000 15:25:57 -0400
Received: from rotala.raleigh.ibm.com (IDENT:narten@localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA24138; Fri, 25 Aug 2000 15:25:13 -0400
Message-Id: <200008251925.PAA24138@rotala.raleigh.ibm.com>
To: "Matt Crawford" <crawdad@fnal.gov>
cc: Alain Durand <alain.durand@Sun.COM>, ipng@sunroof.eng.sun.com,
   crawdad@gungnir.fnal.gov
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02 
In-Reply-To: Message from "Matt Crawford" <crawdad@fnal.gov> 
   of "Fri, 04 Aug 2000 09:46:54 CDT." <200008041446.JAA08699@gungnir.fnal.gov> 
Date: Fri, 25 Aug 2000 15:25:13 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

"Matt Crawford" <crawdad@fnal.gov> writes:

> "Alain Durand" <alain.durand@Sun.COM> writes:
> 
> > > On Thu, Aug 03, 2000 at 01:07:35PM -0500, Matt Crawford wrote:
> > > > Please remove the suggestion that DNS servers 'fabricate
> > > > "dummy" answers'!  The alternative, that nodes register
> > > > random names, is fine.
> > > 
> > > How about registering a PTR record for the prefix, if some server can't
> > > find a PTR record for the address, it could at least find out who owns
> > > the prefix. The result would be just as meaningful as a zone full of
> > > random names.
> > > 
> > > Stig

> > My suggestion was to use a wildcard PTR record for the /64 subnet.
> >     - Alain.

> That ought to do the trick.

Would it? I thought the basic problem is that some servers require
that a PTR record for an address point to a name, and that the
returned name also map back to the address being used. I.e, the issue
isn't just lack of a PTR record.

The current text in the draft still needs changing then though, as the
text that Matt asks to remove really needs to spell out that
"fabricate dummy answers" means for both the reverse and forward
directions. Not something I think is such a great idea.

So, unless I hear otherwise, I will remove the text as suggested.

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 13:59:07 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PKv7P16359
	for ipng-dist; Fri, 25 Aug 2000 13:57:07 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PKuu616352
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 13:56:56 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA13131
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 13:56:55 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20432;
	Fri, 25 Aug 2000 13:56:54 -0700 (PDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id PAA11609;
	Fri, 25 Aug 2000 15:56:48 -0500 (CDT)
Message-Id: <200008252056.PAA11609@gungnir.fnal.gov>
To: Thomas Narten <narten@raleigh.ibm.com>
Cc: Alain Durand <alain.durand@Sun.COM>, ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02 
In-reply-to: Your message of Fri, 25 Aug 2000 15:25:13 EDT.
             <200008251925.PAA24138@rotala.raleigh.ibm.com> 
Date: Fri, 25 Aug 2000 15:56:47 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> > > My suggestion was to use a wildcard PTR record for the /64 subnet.
> > That ought to do the trick.
> Would it? I thought the basic problem is that some servers require
> that a PTR record for an address point to a name, and that the
> returned name also map back to the address being used. I.e, the issue
> isn't just lack of a PTR record.

I have only run into one instance of such a picky-server problem, and
I've been in the situation for a couple of years.  My home subnet is
statically assigned but the [IPv4] ISP won't point the PTRs to my
names, although the forward mappings, which are under my control,
point to the ISP-assigned addresses.  The only problem this seems to
cause is that the MX servers for aol.com won't accept my email unless
I funnel it through the ISP's smtp server.

All other servers seem to be satisfied as long as there's SOMETHING
in the in-addr.arpa.

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

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 14:26:13 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PLObH16382
	for ipng-dist; Fri, 25 Aug 2000 14:24:37 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PLOS616375
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 14:24:29 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA15398
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 14:24:29 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA00309
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 14:24:29 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Aug 2000 14:24:08 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <QA25BT59>; Fri, 25 Aug 2000 14:24:08 -0700
Message-ID: <7695E2F6903F7A41961F8CF888D87EA834789E@red-msg-06.redmond.corp.microsoft.com>
From: Richard Draves <richdr@microsoft.com>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group
	 <ipng@sunroof.eng.sun.com>
Subject: RE: When should mobile nodes use their care-of address, etc... 
Date: Fri, 25 Aug 2000 14:24:25 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> Your proposal is simply too inflexible and I don't understand why
> we can get a policy per user, environment, ... and not a flag.

Actually, the draft says:

   IPv6 implementations SHOULD support configurable address selection 
   via a mechanism at least as powerful as the policy tables defined 
   here. If an implementation is not configurable or has not been 
   configured, then it SHOULD operate according to the algorithms 
   specified here in conjunction with the following default policy 
   table: 

So if you believe the policy table mechanisms in the draft are too
inflexible for mobility, then you are free to invent & implement more
powerful mechanisms.

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 15:11:50 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7PMAPa16417
	for ipng-dist; Fri, 25 Aug 2000 15:10:25 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged))
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7PMAG616410
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 15:10:17 -0700 (PDT)
Received: from eng.sun.com (sappey.Eng.Sun.COM [129.146.85.69])
	by jurassic.eng.sun.com (8.11.0+Sun/8.11.0) with ESMTP id e7PMAFK666020;
	Fri, 25 Aug 2000 15:10:16 -0700 (PDT)
Message-ID: <39A6EE47.3AE27D0B@eng.sun.com>
Date: Fri, 25 Aug 2000 15:08:07 -0700
From: Alain Durand <alain.durand@eng.sun.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Narten <narten@raleigh.ibm.com>
CC: Matt Crawford <crawdad@fnal.gov>, ipng@sunroof.eng.sun.com
Subject: Re: Comment on draft-ietf-ipngwg-addrconf-privacy-02
References: <200008251925.PAA24138@rotala.raleigh.ibm.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thomas Narten wrote:

>
> Would it? I thought the basic problem is that some servers require
> that a PTR record for an address point to a name, and that the
> returned name also map back to the address being used. I.e, the issue
> isn't just lack of a PTR record.

For application like rlogin (and .rhost mechanism), you're right...
But such mechanisms are trying to identify you from your IP address,
so using an address generated according to the privacy draft in such a context
will clearly not work...

    - Alain.


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

From owner-ipng@sunroof.eng.sun.com Fri Aug 25 23:27:53 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7Q6QIP18383
	for ipng-dist; Fri, 25 Aug 2000 23:26:18 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7Q6QA618376
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 23:26:10 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA24453
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 23:26:11 -0700 (PDT)
Received: from web2302.mail.yahoo.com (web2302.mail.yahoo.com [128.11.68.53])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA05173
	for <ipng@sunroof.eng.sun.com>; Fri, 25 Aug 2000 23:26:11 -0700 (PDT)
Message-ID: <20000826062610.13095.qmail@web2302.mail.yahoo.com>
Received: from [38.28.172.28] by web2302.mail.yahoo.com; Fri, 25 Aug 2000 23:26:10 PDT
Date: Fri, 25 Aug 2000 23:26:10 -0700 (PDT)
From: Bruce Dang <xfrog98@yahoo.com>
Subject: IPv6 question
To: ipng@sunroof.eng.sun.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

I have a quick IPv6 question.  In the header there is a "next header field," is there a limit to
this?  For example, if you were to have a really big # of headers following the Ipv6 header and
the remote node have to process every single one of them.  Would this consider a possible dos? 
Thanks.

Cheers,

Bruce

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sat Aug 26 09:24:55 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7QGNbm18949
	for ipng-dist; Sat, 26 Aug 2000 09:23:37 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7QGNS618940
	for <ipng@sunroof.eng.sun.com>; Sat, 26 Aug 2000 09:23:28 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10375
	for <ipng@sunroof.eng.sun.com>; Sat, 26 Aug 2000 09:23:28 -0700 (PDT)
Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03432
	for <ipng@sunroof.eng.sun.com>; Sat, 26 Aug 2000 09:23:26 -0700 (PDT)
Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1])
	by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e7QGN9623967;
	Sat, 26 Aug 2000 18:23:09 +0200
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA26526;
	Sat, 26 Aug 2000 18:23:08 +0200 (MET DST)
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA06983;
	Sat, 26 Aug 2000 18:23:48 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200008261623.SAA06983@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Richard Draves <richdr@microsoft.com>
cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group <ipng@sunroof.eng.sun.com>
Subject: Re: When should mobile nodes use their care-of address, etc... 
In-reply-to: Your message of Fri, 25 Aug 2000 14:24:25 PDT.
             <7695E2F6903F7A41961F8CF888D87EA834789E@red-msg-06.redmond.corp.microsoft.com> 
Date: Sat, 26 Aug 2000 18:23:48 +0200
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

 In your previous mail you wrote:

   > Your proposal is simply too inflexible and I don't understand why
   > we can get a policy per user, environment, ... and not a flag.
   
   Actually, the draft says:
   
      IPv6 implementations SHOULD support configurable address selection 
      via a mechanism at least as powerful as the policy tables defined 
      here. If an implementation is not configurable or has not been 
      configured, then it SHOULD operate according to the algorithms 
      specified here in conjunction with the following default policy 
      table: 
   
   So if you believe the policy table mechanisms in the draft are too
   inflexible for mobility, then you are free to invent & implement more
   powerful mechanisms.
   
=> Will the draft go in the standard track or be published as informational?
In the first case you should not use this kind of answers, in the second
case at least two documents for the standard track (6to4 and privacy IID)
depend on your draft...

Francis.Dupont@enst-bretagne.fr
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug 27 00:25:32 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7R7OHg19403
	for ipng-dist; Sun, 27 Aug 2000 00:24:17 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7R7O8619396
	for <ipng@sunroof.eng.sun.com>; Sun, 27 Aug 2000 00:24:08 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA25263
	for <ipng@sunroof.eng.sun.com>; Sun, 27 Aug 2000 00:24:07 -0700 (PDT)
Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA14815
	for <ipng@sunroof.eng.sun.com>; Sun, 27 Aug 2000 00:24:06 -0700 (PDT)
Received: from localhost (yoshfuji@localhost [127.0.0.1])
	by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id QAA26630
	for <ipng@sunroof.eng.sun.com>; Sun, 27 Aug 2000 16:24:00 +0900
To: ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "IPv6 Node Information Queries"
From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=)
 <yoshfuji@ecei.tohoku.ac.jp>
In-Reply-To: <4.3.2.7.2.20000802142016.02178610@mailhost.iprg.nokia.com>
References: <4.3.2.7.2.20000802142016.02178610@mailhost.iprg.nokia.com>
X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef)
X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15  13 23 18 06 A9 6F 57 00 6B 25
X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000827162358M.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp>
Date: Sun, 27 Aug 2000 16:23:58 +0900
X-Dispatcher: imput version 990905(IM130)
Lines: 28
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

In article <4.3.2.7.2.20000802142016.02178610@mailhost.iprg.nokia.com> (at Wed, 02 Aug 2000 14:23:55 -0700), Bob Hinden <hinden@iprg.nokia.com> says:

> 	Filename : draft-ietf-ipngwg-icmp-name-lookups-06.txt 	

> 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 August 16, 2000.

Maybe too late, but:

Section 4:
|    Finally, if the Qtype is known and the response is allowed by local
|    policy, the Responder must fill in the Flags and Reply Data of the
|    NI Reply in accordance with the definition of the Qtype and transmit
|    the NI Reply with an ICMPv6 source address equal to the Queried
                                                             ~~~~~~~
|    Address, unless that address was an anycast address.  If the Queried
     ~~~~~~~                             ~~~~~~~~~~~~~~~
|    Address was anycast, the source address for the Reply SHOULD be one
|    belonging to the interface on which the Query was received.

How about link-scope multicast addresses such as ff02::1 and NI
group address?

-- 
Hideaki YOSHIFUJI @ USAGI Project  <yoshfuji@v6.linux.or.jp>
Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/
PGP5i FP: F731 6599 5EB2 BBA7 1515  1323 1806 A96F 5700 6B25 
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Sun Aug 27 21:50:38 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7S4nP319864
	for ipng-dist; Sun, 27 Aug 2000 21:49:25 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7S4mT619842;
	Sun, 27 Aug 2000 21:48:29 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA02981;
	Sun, 27 Aug 2000 21:48:27 -0700 (PDT)
Received: from ups.cisco.com (ups.cisco.com [171.69.18.21])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08542;
	Sun, 27 Aug 2000 22:48:27 -0600 (MDT)
Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188])
	by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA20344;
	Sun, 27 Aug 2000 21:48:26 -0700 (PDT)
Mime-Version: 1.0
X-Sender: deering@ups
Message-Id: <v04220802b5cf984ad6c0@[10.19.130.188]>
Date: Sun, 27 Aug 2000 21:48:34 -0700
To: ipng@sunroof.eng.sun.com
From: Steve Deering <deering@cisco.com>
Subject: IPv6 address allocation comments
Cc: Bob Hinden <hinden@iprg.nokia.com>, ngtrans@sunroof.eng.sun.com
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dear IPng Working Group,

The following text was generated by the IPv6 Directorate, IAB, and IESG
as comments on the draft IPv6 address allocation policy developed by the
Regional Internet Registries (RIRs).  Though it is not a product of the
IPng working group, we (the IPng chairs) believe that it is consistent
with the (rough) consensus position of the working group, based on
previous discussions on the ipngwg mailing list, and we wanted to give
the working group a chance to look at it before it goes to the RIRs.
The RIRs will be holding policy meetings starting in mid-September and
the plan is to send these comments to the RIRs on September 1st to give
them time to review it before their meetings, so if you'd like to provide
further input to the text, please do so before Friday of this week.

Steve Deering / Bob Hinden

---------

Comments on IPv6 address allocation guidelines
----------------------------------------------

 -DRAFT--DRAFT---DRAFT----DRAFT-----DRAFT 6 of August 25, 2000
 

During a discussion between IETF and RIR experts at the Adelaide IETF,
a suggestion was made that it might be appropriate to allocate /56 prefixes
instead of /48 for homes and small businesses. However, subsequent
analysis has revealed significant advantages in using /48 uniformly. 
This note is an update following further discussions at the Pittsburgh 
IETF.

By way of preamble, note that IPv6 partitions address space into public
topology and site topology, and the expectation is that the RIRs will 
only need to manage the public topology. However, they may need to
provide guidance and to ensure fairness of address distribution.

Also note that it is widely expected that all IPv6 subscribers,
whether domestic (homes), mobile (vehicles or individuals), or 
enterprises of any size, will eventually possess multiple always-on 
hosts, at least one subnet with the potential for additional
subnetting, and therefore some internal routing capability. 
Note that in the mobile environment, the device connecting
a mobile site to the network may in fact be a third generation
cellular telephone. In other words the subscriber allocation unit 
is not always a host; it is always potentially a site.

This then sets the scene for proposing a fixed boundary
at /48 for all subscribers except the very largest. First we
give the arguments for such a guideline, and then we demonstrate
that it is entirely compatible with responsible stewardship
of the total IPv6 address space. Finally a technical annex
goes into some important details.

The arguments for such a fixed boundary are:

 - only by having an ISP-independent boundary can we guarantee 
   that a change of ISP will not require a costly internal
   restructuring or consolidation of subnets.

 - to enable straightforward site renumbering, i.e. when a site
   renumbers from one prefix to another, the whole process,
   including parallel running of the two prefixes, would be
   greatly complicated if the prefixes had different lengths
   (depending of course on the size and complexity of the site).

 - there are various possible approaches to multihoming for IPv6 sites,
   in addition to the techniques already used for IPv4 multihoming.
   More work remains to be done in this area, but it seems likely that 
   several approaches will be deployed in practice, each with their 
   own advantages and disadvantages. Some (but not all) will work
   better with a fixed prefix boundary. The technical annex
   discusses multihoming in more detail.
     
 - to allow easy growth of the subscribers' networks -- no need
   to keep going back to ISPs for more space (except for that
   relatively small number of subscribers for which a /48 is
   not enough).

 - to get the ISPs and registries out of the business of judging 
   sites' needs for address space, unless the site requests more 
   space than a /48, with several advantages:

   - ISPs no longer need to ask for details of their customers' 
     network architecture and growth plans
   - ISPs and registries no longer have to judge rates of address
     consumption by customer type
   - registry operations will be made more efficient by reducing
     the need for evaluations and judgements
   - address space will no longer be a precious resource for customers,
     removing the major incentive for subscribers to install v6/v6 NATs, 
     which would defeat the ability of IPv6 to restore address transparency.

 - to allow the site to maintain a single reverse-DNS zone covering
   all prefixes.

   - If and only if a site can use the same subnetting structure
     under each of its prefixes, then it can use the same zone file
     for the address-to-name mapping of all of them.  And, using the
     conventions of RFC 2874, it can roll the reverse mapping data
     into the "forward" (name-keyed) zone.

Specific advantages of the fixed boundary being at /48 include

 - to leave open the technical option of retro-fitting the GSE
   (Global, Site and End-System Designator, a.k.a "8+8")
   proposal for separating locators and identifiers, which assumes
   a fixed boundary between global and site addressing at /48. 
   Although the GSE technique was deferred a couple of years ago,
   it still has strong proponents.  Also, the IRTF Namespace 
   Research Group is actively looking into topics closely related 
   to GSE.  It is still possible that GSE or a derivative of GSE 
   will be used with IPv6 in the future.

 - since the site local prefix is fec0::/48, global site prefixes
   of /48 will allow sites to easily maintain a simple 1 to 1 
   mapping between the global topology and the site local topology 
   in the SLA field.

 - similarly, if the 6to4 proposal is standardized, migration from
   a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix 
   will be simplified if the native prefix is /48

 - existing running code and products conforming to existing RFCs

Note that none of these reasons imply an expectation that
homes, vehicles, etc. will intrinsically require 16 bits of 
subnet space.

The question naturally arises whether giving a /48 to every
subscriber represents a profligate waste of address space.
Objective analysis shows that this is not the case. A /48
prefix under the Aggregatable Global Unicast Address (TLA) 
format prefix actually contains 45 variable
bits, i.e. the number of available prefixes is 2**45
or about 35 trillion (35,184,372,088,832). If we take the
limiting case of assigning one prefix per human, then the 
utilization of the TLA space appears to be limited to 
approximately 0.03% on reasonable assumptions. 

More precisely,

 - RFC 1715 defines an "H ratio" based on experience in
   address space assignment in various networks. Applied
   to a 45 bit address space, and projecting a world
   population of 10.7 billion by 2050 (see
   http://www.popin.org/pop1998/ ), the required
   assignment efficiency is log_10(1.07*10^10) / 45 = 0.22.  
   This is less than the efficiencies of telephone numbers and 
   DECnetIV or IPv4 addresses shown in RFC 1715, i.e. gives
   no grounds for concern.

 - We are highly confident in the validity of this analysis,
   based on experience with IPv4 and several other address spaces,
   and on extremely ambitious scaling goals for the Internet
   amounting to an 80 bit address space *per person*. Even so,
   being acutely aware of the history of under-estimating demand,
   we have reserved more than 85% of the address space (i.e. the
   bulk of the space not under the Aggregatable Global Unicast 
   Address (TLA) format prefix).   
   Therefore, if the analysis does one day turn out to be wrong, 
   our successors will still have the option of imposing much more 
   restrictive allocation policies on the remaining 85%.

 - It has been suggested that even if the above analysis is valid
   for terrestrial and near-Earth networks, it may fail for
   interplanetary networking and beyond. This is conceivable, but 
   the challenges in dealing with packet transit times of many minutes
   or more, and with such remote deployment, are such as to turn 
   addressing into a side issue.

 - For transient use by non-routing hosts (e.g., temporary addresses 
   acquired and released while passing through wireless cells, and 
   for stand-alone dial-up users who prefer transient addresses for 
   privacy reasons), a prefix longer than /48 would be OK. But a
   subscriber who wants "static" IPv6 address space ought
   to be allocated a /48 for the reasons given above.

Final comments:

We argue that although careful stewardship of IPv6 address space
is essential, this is completely compatible with the convenience
and simplicity of a uniform prefix size for IPv6 sites of any size.
The numbers are such that there seems to be no objective risk
of running out of space, giving an unfair amount of space to
early customers, or of getting back into the over-constrained
IPv4 situation where address conservation and route aggregation
damage each other.

----

Technical Annex

The technical principles that apply to address allocation seek to balance 
healthy conservation practices and wisdom with a certain ease of access. On 
one hand, with any resource, one wants to spend wisely; the housewife in 
the bazaar doesn't spend more than she needs to for a purchase even if her 
purse is unlimited. On the other hand, the IPv6 address space is in no sense 
as precious a resource as the IPv4 address space, and unwarranted 
conservatism acts as a disincentive in a marketplace already dampened by 
other factors. So from a market development perspective, we would like to 
see it be very easy for a user or an ISP to obtain as many IPv6 addresses as 
she really needs without a prospect of immediate renumbering or of scaling 
inefficiencies.

The IETF makes no comment on business issues or relationships. However, in 
general, we observe that technical delegation policy can have strong 
business impacts. For example, early versions of the IPv6 addressing 
architecture proposed that the 50-60 dominant IPv4 ISPs (as demonstrated in 
http://www.caida.org/analysis/topology/as_core_network/AS_Network.xml and 
http://www.telstra.net/ops/bgptable.html) be given sweeping allocations, 
and permitted to redelegate subsets of them to their downstream peers. This 
would have the technical effect of biasing routing of traffic between those 
lesser ISPs through their upstream neighbors. To avoid that, the lesser 
ISPs would be forced to arrange special-case punch-through agreements with 
their other peers, as they do now in the IPv4 world. This would tend to 
lock in existing Tier 1 and Tier 2 operators indefinitely. In 
addition, technically, routing would suffer; it is desirable for every ISP's 
traffic to be routed by the best available path consistent with policy, and 
to be resilient to temporary outages, rather than seeing traffic to be 
biased through a few operators for potentially historic reasons. One would 
like to achieve this as a natural result rather than having to consciously 
counteract the aggregation of addresses. So a strong requirement of the 
address delegation plan is that it not be predicated on or unduly bias 
business relationships or models.

The IPv6 address, as currently defined, consists of 64 bits of "network 
number" and 64 bits of "host number". The technical reasons for this are 
several. The requirements for IPv6 agreed to in 1993 included a plan to be 
able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split 
effectively accomplishes this. Procedures used in host address assignment, 
such as the router advertisement of a network's prefix to hosts, which in 
turn place a locally unique number in the host portion, depend on this 
split. Examples of obvious choices of host number (IEEE Mac Address, E.164 
number, E.214 IMSI, etc) suggest that no assumption should be made that 
bits may be stolen from that range for subnet numbering; current generation 
MAC layers and E.164 numbers specify up to 64 bit objects. Therefore, subnet 
numbers must be assumed to come from the network part. This is not to 
preclude routing protocols such as IS-IS level 1 (intra-area) routing, 
which routes individual host addresses, but says that it may not be 
depended upon in the world outside that zone.

The IETF has also gone to a great deal of effort to minimize the impacts of 
network renumbering. None-the-less, renumbering of IPv6 networks is neither 
invisible nor completely painless. Therefore, renumbering should be 
considered an acceptable event, but to be avoided if reasonably avoidable.


The IETF's IPNG working group has recommended that the address block given 
to a single edge network which may be recursively subnetted be a 48 bit 
prefix. This gives each such network 2^16 subnet numbers to use in routing, 
and a very large number of unique host numbers within each network. This is 
deemed to be large enough for most enterprises, and to leave plenty of room 
for delegation of address blocks to aggregating entities.

It is not obvious, however, that all edge networks are likely to be 
recursively subnetted; an individual PC in a home, or a single cell in a 
mobile telephone network, for example, may or may not be further 
subnetted (depending whether they are acting as gateways to personal, 
home, or vehicular networks). When a network number is delegated to a place 
which will not require subnetting, therefore, wisdom suggests that it be given 
a single 64 bit prefix - perhaps shared among the dial-in connections to the 
same ISP router. It is suggested that business practices therefore consider 
whether the edge network is or is not likely to be recursively subnetted, 
and allocate /48 or /64 prefixes accordingly. However this decision may be 
taken in the knowledge that there is objectively no shortage of /48s,
and the expectation that personal, home and vehicle networks will
become the norm.


The RIR communities, with the IAB, have determined that reasonable address 
prefixes delegated to service providers should be on the order of 29 to 35 
bits in length, giving individual delegations support for 2^13 (8K) to 2^19 
(512K) subscriber networks. Allocations are to be given in a manner such 
that an initial prefix may be subsumed by subsequent larger allocations 
without forcing existing subscriber networks to renumber. We concur that 
this meets the technical requirement for manageable and scalable backbone 
routing while simultaneously allowing for managed growth of individual 
delegations.

The same type of rule could be used in the allocation of addresses in edge 
networks; if there is doubt whether an edge network will in turn be 
subnetted, the edge network might be encouraged to allocate the first 64 
bit prefix out of a block of 8..256, preserving room for growth of that 
allocation without renumbering up to a point.


In the realm of multi-homed networks, the techniques used in IPv4 can all 
be applied, but they have known scaling problems. Specifically,
if the same prefix is advertised by multiple ISPs, the routing tables
will grow as a function of the number of multihomed sites. To go beyond this
for IPv6, we only have initial proposals on the table at this time,
and active work is under way in the IETF IPNGWG working group. 

Key characteristics of a definitive multi-homing proposal 
include (at minimum) that it provides routing connectivity to any 
multi-homed network globally, conserves address space, produces high 
quality routes at least as well as the single-homed host case previously 
discussed via any of the network's providers, enables a multi-homed network 
to connect to multiple ISPs, does not inherently bias routing to use any 
proper subset of those networks, does not unduly damage route
aggregation, and scales to very large numbers of multi-homed networks.

One class of solution being considered amounts to permanent parallel running 
of two (or more) prefixes per site.  In the absence of a fixed prefix boundary, 
such a site might be required to have multiple different internal 
subnet numbering strategies, (one for each prefix length) or, if it 
only wanted one, be forced to use the most restrictive one as defined by 
the longest prefix it received from any of its ISPs. 
In this approach, a multi-homed network would have an address 
block from each of its upstream providers. Each host would either
have exactly one address picked from the set of upstream 
providers, or one address per host from each of the upstream providers.
The first case is essentially a variant on RFC 2260, with known scaling
limits.

In the second case (multiple addresses per host), if two multi-homed networks 
communicate, having respectively m and n upstream providers, then the one 
initiating the connection will select one address pair from the n*m 
potential address pairs to connect from and to, and in so doing will select 
the providers, and therefore the applicable route, for the life of the 
connection. Given that each path will have a different ambient bit rate, 
loss rate, and delay, if neither host is in possession of any routing 
or metric information, the initiating host has only a 1/(m*n) probability 
of selecting the optimal address pair. Work on better-than-random address
selection is in progress in the IETF, but is incomplete. In addition, use 
of a singly-announced address for a long-lived session exposes that session to 
being broken by routing outages, near the source and elsewhere in the 
network. This approach also tends to encourage ASPs who offer a 
service of bypassing end-to-end IP routing to improve user response times, 
often known as "content-based routing".

An existence proof exists in the existing IPv4 Internet that a network whose 
address is distinct from and globally advertised to all upstream providers 
permits the routing network to select the optimal path within the 
applicable policy. Present-day routing policies are not QoS policies but 
reachability policies, which means that they will not necessarily select 
the optimal delay, bit rate, or loss rate, but the route will be the best 
within the metrics that are indeed in use. One may therefore conclude that 
this would work correctly for IPv6 networks as well, apart from scaling issues.

It would be useful to study a more scalable version of the latter approach for
IPv6. One interim option is to allocate 29-35 bit prefixes regionally, and 
allocate /48 prefixes out of them to multi-homed networks they contain or 
touch. Within the region, each such /48 is globally advertised. Outside the 
region, the /29-/35 bit prefix may be advertised, to improve aggregation and 
scaling. A multi-homed network which spans multiple regions may use an address 
block from each region, and internally advertise its addresses to stop the edge 
network from inappropriately using external connectivity for internal 
traffic. In this context, the word "region" is intentionally vague but
relates more to network topology than to geography. The GSE proposal also
tackled multihoming somewhat in this way.

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

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 05:05:23 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SC43r20063
	for ipng-dist; Mon, 28 Aug 2000 05:04:03 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SC3r620056
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 05:03:53 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA13009
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 05:03:52 -0700 (PDT)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06756
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 05:03:51 -0700 (PDT)
Received: from zrchb213.us.nortel.com (actually zrchb213) 
          by smtprch2.nortel.com; Sun, 27 Aug 2000 12:28:13 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <RTY7WPTR>; Sun, 27 Aug 2000 12:31:48 -0500
Message-ID: <F033F6FEF3F1D111BD150000F8CD1431047F6532@zcard007.ca.nortel.com>
From: "Peter Tam" <ptam@nortelnetworks.com>
To: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
Subject: RE: W.G. Last Call on "IPv6 Node Information Queries"
Date: Sun, 27 Aug 2000 12:31:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0104C.ABB6B290"
X-Orig: <ptam@americasm01.nt.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0104C.ABB6B290
Content-Type: text/plain;
	charset="iso-8859-1"

Bob:

Section 3, NI Messages: on explaining the last field "Data", which reads:
"In a Reply, Qtype-specific data present only when the ICMPv6 Type field is
zero.....". How could the ICMPv6 Type field be 0, when it can only take on
139 and 140 for NI Query and Reply respectively. Should it not be Code 0,
which indicates a successful operation that may carry data in its reply?

Sorry if it was clarified before.
Thanks....Peter Tam,
Nortel Networks

	-----Original Message-----
	From:	Bob Hinden [SMTP:hinden@iprg.nokia.com]
	Sent:	Wednesday, August 02, 2000 5:24 PM
	To:	ipng@sunroof.eng.sun.com
	Subject:	W.G. Last Call on "IPv6 Node Information Queries"

	This is a IPng 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-06.txt 	
		Pages : 14
		Date : 20-Jul-00

	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 August 16, 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
	--------------------------------------------------------------------

------_=_NextPart_001_01C0104C.ABB6B290
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: W.G. Last Call on &quot;IPv6 Node Information =
Queries&quot;</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bob:</FONT>
</P>

<P><U><FONT SIZE=3D2 FACE=3D"Arial">Section 3, NI =
Messages</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">: on explaining the =
last field "Data", which reads: "In a Reply, Qtype-specific data =
present only when the ICMPv6 Type field is zero.....". How could the =
ICMPv6 Type field be 0, when it can only take on 139 and 140 for NI =
Query and Reply respectively. Should it not be Code 0, which indicates =
a successful operation that may carry data in its reply?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Sorry if it was clarified =
before.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks....Peter Tam,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Nortel Networks</FONT>
</P>
<UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Bob Hinden =
[SMTP:hinden@iprg.nokia.com]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Wednesday, August 02, 2000 5:24 PM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">ipng@sunroof.eng.sun.com</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">W.G. Last Call on &quot;IPv6 Node =
Information Queries&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is a IPng working group last call =
for comments on advancing the </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">following document as a Proposed =
Standard:</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Title : IPv6 Node Information Queries</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Author(s) : M. Crawford</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Filename : draft-ietf-ipngwg-icmp-name-lookups-06.txt =
&nbsp; </FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Pages : 14</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Date : 20-Jul-00</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Please send substantive comments to =
the ipng mailing list, and minor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">editorial comments to the =
author.&nbsp; This last call period will end two</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">week from today on August 16, =
2000.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bob Hinden / Steve Deering</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IETF IPng Working Group Mailing =
List</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IPng Home =
Page:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://playground.sun.com/ipng" =
TARGET=3D"_blank">http://playground.sun.com/ipng</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">FTP =
archive:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"ftp://playground.sun.com/pub/ipng" =
TARGET=3D"_blank">ftp://playground.sun.com/pub/ipng</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Direct all administrative requests to =
majordomo@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0104C.ABB6B290--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 08:11:33 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SFACJ20193
	for ipng-dist; Mon, 28 Aug 2000 08:10:12 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SF9x620186
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 08:10:00 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA19525
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 08:09:59 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18096
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 08:09:59 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12234;
	Mon, 28 Aug 2000 11:09:56 -0400 (EDT)
Message-Id: <200008281509.LAA12234@ietf.org>
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: IP Version 6 Management Information Base for the
	 Multicast Listener Discovery Protocol to Proposed Standard
Reply-to: iesg@ietf.org
Date: Mon, 28 Aug 2000 11:09:56 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


The IESG has received a request from the IPNG Working Group to consider
IP Version 6 Management Information Base for the Multicast Listener
Discovery Protocol <draft-ietf-ipngwg-mld-mib-04.txt> as a Proposed
Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-04.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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 08:31:55 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SFURm20238
	for ipng-dist; Mon, 28 Aug 2000 08:30:27 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SFUE620231
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 08:30:14 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA01538
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 08:30:14 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13172
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 08:30:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12833;
	Mon, 28 Aug 2000 11:30:10 -0400 (EDT)
Message-Id: <200008281530.LAA12833@ietf.org>
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: Extensions to IPv6 Neighbor Discovery for Inverse
	 Discovery Specification to Proposed Standard
Reply-to: iesg@ietf.org
Date: Mon, 28 Aug 2000 11:30:10 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


The IESG has received a request from the IPNG Working Group to consider
Extensions to IPv6 Neighbor Discovery for Inverse Discovery
Specification <draft-ietf-ion-ipv6-ind-04.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by September 8, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ion-ipv6-ind-04.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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 09:02:49 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SG1Kf20281
	for ipng-dist; Mon, 28 Aug 2000 09:01:20 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SG19620274
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 09:01:09 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA00369
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 09:01:08 -0700 (PDT)
Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20167
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 10:01:07 -0600 (MDT)
Received: from gungnir.fnal.gov (localhost [127.0.0.1])
	by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA25494;
	Mon, 28 Aug 2000 11:01:04 -0500 (CDT)
Message-Id: <200008281601.LAA25494@gungnir.fnal.gov>
To: Bob Hinden <hinden@iprg.nokia.com>
Cc: ipng@sunroof.eng.sun.com
From: "Matt Crawford" <crawdad@fnal.gov>
Subject: Re: W.G. Last Call on "IPv6 Node Information Queries" 
In-reply-to: Your message of Wed, 02 Aug 2000 14:23:55 PDT.
             <4.3.2.7.2.20000802142016.02178610@mailhost.iprg.nokia.com> 
Date: Mon, 28 Aug 2000 11:01:04 -0500
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

> This is a IPng 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-06.txt 	

I received three comments:

On page 3, "Type" should be "Code" in this line (Tam):

                Qtype-specific data present only when the ICMPv6 Type
                field is zero.  The length of the Data may be inferred
 

On page 5, "Type" should be "Code" in this line (Jinmei):

    Reply with ICMPv6 Type = 2 and no Reply Data.  The Responder should
 

Later on page 5, two mentions of "anycast" in this passage should be
"anycast or multicast" (Yoshifuji):

    [...] and transmit
    the NI Reply with an ICMPv6 source address equal to the Queried
    Address, unless that address was an anycast address.  If the Queried
    Address was anycast, the source address for the Reply SHOULD be one
    belonging to the interface on which the Query was received.


I propose to make these changes and to renumber the sections so that
the Abstract is unnumbered (in accord with rfced custom) and submit
the -07 draft as final.  All right?

				Matt
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 11:28:52 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SIRQw20423
	for ipng-dist; Mon, 28 Aug 2000 11:27:26 -0700 (PDT)
Received: from stinker.eng.sun.com (stinker [129.146.86.121])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SIRI620416
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 11:27:19 -0700 (PDT)
Received: (from jrh@localhost)
	by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e7SIR5308159
	for ipng@sunroof.eng.sun.com; Mon, 28 Aug 2000 11:27:06 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SDvg620144
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 06:57:42 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA08469
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 06:57:43 -0700 (PDT)
Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13966
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 06:57:42 -0700 (PDT)
Received: from kanagw970.kanagawa.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id WAA06364; Mon, 28 Aug 2000 22:57:41 +0900 (JST)
Received: by kanagw970.kanagawa.hitachi.co.jp (8.9.0/3.6Wbeta6-GPCD) id WAA03933; Mon, 28 Aug 2000 22:57:41 +0900 (JST)
Message-Id: <200008281357.WAA03933@kanagw970.kanagawa.hitachi.co.jp>
X-Sender: tsuchiya@158.214.152.195
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32)
Date: Mon, 28 Aug 2000 22:58:49 +0900
To: ipng@sunroof.eng.sun.com
From: Kazuaki Tsuchiya <tsuchiya@kanagawa.hitachi.co.jp>
Subject: RE: IPv6 Router
In-Reply-To: <Pine.SOL.4.20.0008251200460.2292-100000@penelope.ecs.soton
 .ac.uk>
References: <4B6BC00CD15FD2119E5F0008C7A419A5089EB1C0@eaubrnt018.epa.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Dear IPv6 folks,

Hitachi is ready for delivery of IPv6 "beta" software for its 
GR2000 Gigabit Router family not only to Japanese market but
to other many countries in response to customers' request. So
would you please contact us(mailto: info-net@kanagawa.hitachi.co.jp)
if you have interest in them? We are pleased to answer your
questions.

Thanks.

-- Kazuaki Tsuchiya, Hitachi.

> Nortel/Bay Networks has IPv6 enabled through their product line
> in software. Also, Hitachi has a production router running IPv6,
> but is available only in Asia.  You should also look at Ipsilon. 
>


------------------------------------------------------------
Kazuaki Tsuchiya (mailto:tsuchiya@kanagawa.hitachi.co.jp)
Hitachi,Ltd. Enterprise Server Division  Fax:+81(463)87-7341

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

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 12:27:37 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SJQDZ20518
	for ipng-dist; Mon, 28 Aug 2000 12:26:14 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SJQ2620511;
	Mon, 28 Aug 2000 12:26:02 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA22256;
	Mon, 28 Aug 2000 12:26:01 -0700 (PDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27783;
	Mon, 28 Aug 2000 12:26:01 -0700 (PDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 80CB42259; Mon, 28 Aug 2000 15:26:00 -0400 (EDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id 5598A23B0; Mon, 28 Aug 2000 15:26:00 -0400 (EDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id PAA0001030265; Mon, 28 Aug 2000 15:24:24 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008281924.PAA0001030265@anw.zk3.dec.com>
To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com,
   dhcp-v6@bucknell.edu, members@ipv6forum.com, tech@ipv6forum.com
Cc: reinhard.scholl@etsi.fr
Subject: UPDATE: IPv6 ETSI Test Event Web Page Pointer
Date: Mon, 28 Aug 2000 15:24:23 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

  ** PLEASE DO NOT RESPOND TO THIS MAIL **

Folks,

Just wanted to add that the test/interoperability suites that will be
done for the attached will include test suites from Ericsson provided to
Francis Dupont and his team.  It will not just be a last minute effort for 
testing but a well thought out group of test assertions and procedures.  

Thank You Ericsson for your assistance on this IPv6 implementation
effort.

thanks
/jim

--------------------------------

Hi Folks,

Even though UNH cannot participate in this test event our colleagues
under the guidance of Francis Dupont at ENST in France have come to the
aid of IPv6 developers (thank you ENST and Francis) and working with
Reihhard Scholl there will be an IPv6 test event Oct 2-6.

I believe this is a very important event and vendors should really try
to attend.  Plus it is in a nice place "French Riviera" not that there
won't be a lot of hard work done of course.  This is serious stuff folks
and 3GPP needs our support and this test event.  Please see the
following URL:

http://www.etsi.org/bake-off

regards and thanks for your support,
/jim


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

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 12:33:05 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7SJW9620564
	for ipng-dist; Mon, 28 Aug 2000 12:32:09 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7SJW0620557
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 12:32:00 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA05655
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 12:32:00 -0700 (PDT)
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00404
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 12:31:59 -0700 (PDT)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Mon, 28 Aug 2000 14:28:03 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Q65JKR71>; Mon, 28 Aug 2000 14:31:42 -0500
Message-ID: <F908F961B7CDD111BC720000F8073E43044A1DC7@crchy271.us.nortel.com>
From: "Glenn Morrow" <gmorrow@nortelnetworks.com>
To: "'Bruce Dang'" <xfrog98@yahoo.com>, ipng@sunroof.eng.sun.com
Subject: RE: IPv6 question
Date: Mon, 28 Aug 2000 14:31:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C01126.93587050"
X-Orig: <gmorrow@americasm01.nt.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C01126.93587050
Content-Type: text/plain

As long as the node can be tracked down then there is the threat of
retribution. Before ingress filtering, there was no threat of retribution as
anyone could put any source address in any packet and send it to the
destination. With ingress filtering the packet should be dropped close to
the source if they are using a bogus address. If they are using a correct
source then they will be able to be tracked and prosecuted.

Bloating options is just one method for dos attack. The threat of
retribution ensured by ingress filtering is the general solution as I
understand it.

> -----Original Message-----
> From:	Bruce Dang [SMTP:xfrog98@yahoo.com]
> Sent:	Saturday, August 26, 2000 1:26 AM
> To:	ipng@sunroof.eng.sun.com
> Subject:	IPv6 question
> 
> I have a quick IPv6 question.  In the header there is a "next header
> field," is there a limit to
> this?  For example, if you were to have a really big # of headers
> following the Ipv6 header and
> the remote node have to process every single one of them.  Would this
> consider a possible dos? 
> Thanks.
> 
> Cheers,
> 
> Bruce
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> --------------------------------------------------------------------
> 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
> --------------------------------------------------------------------

------_=_NextPart_001_01C01126.93587050
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: IPv6 question</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As long as the node =
can be tracked down then there is the threat of retribution. Before =
ingress filtering, there was no threat of retribution as anyone could =
put any source address in any packet and send it to the destination. =
With ingress filtering the packet should be dropped close to the source =
if they are using a bogus address. If they are using a correct source =
then they will be able to be tracked and prosecuted.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Bloating options is =
just one method for dos attack. The threat of retribution ensured by =
ingress filtering is the general solution as I understand =
it.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Bruce Dang [SMTP:xfrog98@yahoo.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Saturday, August 26, 2000 1:26 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">ipng@sunroof.eng.sun.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">IPv6 question</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a quick IPv6 question.&nbsp; In =
the header there is a &quot;next header field,&quot; is there a limit =
to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this?&nbsp; For example, if you were =
to have a really big # of headers following the Ipv6 header and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the remote node have to process every =
single one of them.&nbsp; Would this consider a possible dos? </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Thanks.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bruce</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">__________________________________________________</FONT>=

<BR><FONT SIZE=3D2 FACE=3D"Arial">Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Yahoo! Mail - Free email you can =
access from anywhere!</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://mail.yahoo.com/" =
TARGET=3D"_blank">http://mail.yahoo.com/</A></FONT></U>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IETF IPng Working Group Mailing =
List</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IPng Home =
Page:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://playground.sun.com/ipng" =
TARGET=3D"_blank">http://playground.sun.com/ipng</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">FTP =
archive:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U>=
 <FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"ftp://playground.sun.com/pub/ipng" =
TARGET=3D"_blank">ftp://playground.sun.com/pub/ipng</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Direct all administrative requests to =
majordomo@sunroof.eng.sun.com</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">---------------------------------------------------------=
-----------</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C01126.93587050--
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 19:57:19 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7T2u2G20802
	for ipng-dist; Mon, 28 Aug 2000 19:56:02 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7T2tr620795
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 19:55:54 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA27863
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 19:55:53 -0700 (PDT)
Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA02263
	for <ipng@sunroof.eng.sun.com>; Mon, 28 Aug 2000 19:55:52 -0700 (PDT)
Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345)
	id 757901020; Mon, 28 Aug 2000 21:55:52 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail02.ztx.compaq.com (Postfix) with ESMTP
	id 6EB42133E; Mon, 28 Aug 2000 21:55:51 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id WAA0000585651; Mon, 28 Aug 2000 22:54:15 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008290254.WAA0000585651@anw.zk3.dec.com>
To: Thomas Narten <narten@raleigh.ibm.com>
Cc: Jim Bound <bound@zk3.dec.com>, Bob Hinden <hinden@iprg.nokia.com>,
   ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "Privacy Extensions for Stateless Address Autoconfiguration in IPv6s" 
In-reply-to: Your message of "Fri, 25 Aug 2000 15:13:50 EDT."
             <200008251913.PAA24090@rotala.raleigh.ibm.com> 
Date: Mon, 28 Aug 2000 22:54:14 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thomas,

>> >4.  Implications of Changing Interface Identifiers
>> >
>> >   The IPv6 addressing architecture goes to great lengths to ensure that
>> >  interface identifiers are globally unique. During the IPng
>> >   discussions of the GSE proposal [GSE], it was felt that keeping
>> >   interface identifiers globally unique in practice might prove useful
>> >  to future transport protocols. Usage of the algorithms in this
>> >   document would eliminate that future flexibility.
>
>> Can we get more words that this spec does not eliminate users who want
>> to use identifiers that are globally unique by ignoring this entire
>> spec?

>I'm not sure what more you want the document to say. Can you be more
>specific? Here is my reasoning. I think it is true that if anonymous
>addresses become widely used in practice, the fact will be that a
>large proportion of addresses will not have globally unique
>identifiers in interface identifier part of an address. It may well be
>that future uses of globally unique interface identifiers only makes
>sense if the vast majority of addresses do have a globally unique
>component. I.e, will such a scheme even be useful if only 80% of the
>addresses have unique interface identifiers? What if the percentage is
>only 50%?

OK your making it hard for me then.  I do not think this spec should be
permitted to override the 4 year consensus of the IPng working group and
a lot of very contributory folks to make interface identifiers globally
unique.  This spec should not be mandatory but a "suggestion".   What
is happening now is what the U.S. government is doing lately.  The
draft provides assistance to a "potential" threat/problem, which is fine.  
But, it should be optional and not mandatory in any manner at all.  But
instead because the IPng WG may accept the draft users and implementors
now are put under a set of rules that override the existing and
concensus Addr Arch document.  Back to the U.S. comment analogy we use
the goverment for help but they stretch their role beyond our U.S.
Constitution as example in our country.

I don't care if 3% of the users want to have or need global unique
identifiers if they don't want  to worry about random-bad-person
listening to the FDDI WDM packets its their right to with IPv6.  All we
can do is provide an optional hook not mandate it and I think the draft
in that sense over steps its bounds.  

>> Also I waited to respond cause I asked 3 sys admins of very large
>> networks to tell me if they would shut this off on an IPv6
>> implementation.  All said yes and it appears the IETF had to play
>> some poltics here.  This is just plain silly for corporate
>> Intranets.

>I tend to agree that anonymous addresses may not be appropriate in
>some environments. One of the issues you are really getting at is
>where the knobs to control useage of anonymous addresses should be. I
>think a case can be made that the site should be able to disable their
>usage (i.e, it may be corporate policy to do this). Should an end user
>have the ability to override such a policy? In a corporate setting,
>the answer is quite possibly no. But if a user is at home, and the
>policy is set by the ISP, what then?

Thats a result of the issue I am getting at.  My issue is very simple.
The owner of user policy should have the right to ignore this entire
privacy issue is my point.  The goal of this drafts work should be to
provide a technical means as a mechanism to prevent not a police state
view of interface identifiers within a standards document.  Also I ship
products all over the world.  One country might have a completely
different view of "privacy" than does the U.S. jargon and privacy
paranoid potential.   

As far as the knobs thats another discussion.

>> Hence, I suggest that some words be stated that for corproate Intranet
>> traffic this is may be very unnecessary.

>How about I add the following lines to paragraph 2 in Section 4.:

>>    The desires of protecting individual privacy vs. the desire to
>>    effectively maintain and debug a network can conflict with each
>>    other. Having clients use addresses that change over time will make
>>    it more difficult to track down and isolate operational problems. For
>>    example, when looking at packet traces, it could become more
>>    difficult to determine whether one is seeing behavior caused by a
>>    single errant machine, or by a number of them.

The words above completely miss my point.  The reason a user may
not want to be protected by "individual privacy" is simply because they
think its nobodys business in the first place not to just debug
networks, which I would argue is a side-benefit of not doing any absurd
things to control the behavior of networks that have nothing to do with
implementation interoperability which this draft has nothing to do with
but in fact could cause that problem in the market.

>new line:

>     Consequently, system administrators in environments where privacy
>     is not a primary concern (e.g., corporate intranets) may choose
>     to prohibit the assignment and usage of anonymous addresses on
>     the nodes that it manages.

OK I can live with this as it does what I think the affect should be 
from my words above.

But I think it important what I was getting at and will be a source of
my disagreement with many other things we work on together over the
years.  Our job is to provide the implementors and market with the basic
tools to run networks and make them work.  Not tell them how networks
should work, and I think we often travel down that slippery slope in the
IETF and in this draft.  But I realize this whole issue caused the
problem and even the thinking.  How many times do we use the phone, or
even the Internet today.  I am far more paranoid and concerned that
networks become so rigid from our standards process that they perform
poorly.  Using anonymous addresses is just another notch in stealing
cycles and performance from end nodes yet again in the IPv6 era of
creeping featurism as we enter the new millenia, and yet more knobs to
document for users within IPv6.

But also I think the technical solution you propose in the spec is very
elegant, I just don't think it should be mandatory, but a means to
prevent the privacy abuse potential as a "CHOICE".

thanks
/jim

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

From owner-ipng@sunroof.eng.sun.com Mon Aug 28 20:12:54 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7T3BLg20845
	for ipng-dist; Mon, 28 Aug 2000 20:11:21 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7T3BC620838;
	Mon, 28 Aug 2000 20:11:13 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA27494;
	Mon, 28 Aug 2000 20:11:13 -0700 (PDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA07149;
	Mon, 28 Aug 2000 20:11:12 -0700 (PDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id B971D2FBF; Mon, 28 Aug 2000 22:11:11 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP
	id 07D602FA6; Mon, 28 Aug 2000 22:11:11 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id XAA0000588078; Mon, 28 Aug 2000 23:11:08 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008290311.XAA0000588078@anw.zk3.dec.com>
To: Steve Deering <deering@cisco.com>
Cc: ipng@sunroof.eng.sun.com, Bob Hinden <hinden@iprg.nokia.com>,
   ngtrans@sunroof.eng.sun.com, bound@zk3.dec.com
Subject: Re: (ngtrans) IPv6 address allocation comments 
In-reply-to: Your message of "Sun, 27 Aug 2000 21:48:34 PDT."
             <v04220802b5cf984ad6c0@[10.19.130.188]> 
Date: Mon, 28 Aug 2000 23:11:07 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Excellent work and every word of it.  I can't see how anyone can argue
against it but I bet someone will.  Nice IPv6 document too.

p.s. One Nit - I have noticed the word "she" in the text please make all
references to be gender-neutral.  In the seventies and eighties we fixed
at least in this profession the reference to ownership or pronounns
from he, his, or him to gender-neutral statements.  Likewise I don't
want to see "she" or "her" please make this document gender-neutral.

regards,
/jim 


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

From owner-ipng@sunroof.eng.sun.com Tue Aug 29 04:10:54 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7TB9NS21123
	for ipng-dist; Tue, 29 Aug 2000 04:09:23 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7TB9D621116
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 04:09:13 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA01193
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 04:09:12 -0700 (PDT)
Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27712
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 04:09:11 -0700 (PDT)
Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1])
	by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id HAA03452;
	Tue, 29 Aug 2000 07:08:29 -0400
Message-Id: <200008291108.HAA03452@hygro.adsl.duke.edu>
To: Jim Bound <bound@zk3.dec.com>
cc: Bob Hinden <hinden@iprg.nokia.com>, ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "Privacy Extensions for Stateless Address Autoconfiguration in IPv6s" 
In-Reply-To: Message from Jim Bound <bound@zk3.dec.com> 
   of "Mon, 28 Aug 2000 22:54:14 EDT." <200008290254.WAA0000585651@anw.zk3.dec.com> 
Date: Tue, 29 Aug 2000 07:08:29 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Jim,

It is not the intention of this document that it be
mandatory-to-implement for IPv6 devices. It is an elective standard,
meaning it gets implemented by those who find it useful.

>From the abstract:

> This document describes an optional extension to IPv6 stateless
> address autoconfiguration for interfaces whose interface identifier is
> derived from an IEEE identifier.

>From the introduction:

> This document discusses concerns associated with the embedding of
> non-changing interface identifiers within IPv6 addresses and describes
> optional extensions to stateless address autoconfiguration that can
> help mitigate those concerns in environments where such concerns are
> significant.

Is the "optional" wording not strong enough?

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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug 29 07:01:01 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7TDxPI21195
	for ipng-dist; Tue, 29 Aug 2000 06:59:25 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7TDxH621188
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 06:59:17 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA28684
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 06:59:17 -0700 (PDT)
Received: from ztxmail01.ztx.compaq.com (ztxmail01.ztx.compaq.com [161.114.1.205])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05062
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 07:59:16 -0600 (MDT)
Received: by ztxmail01.ztx.compaq.com (Postfix, from userid 12345)
	id 5D50B2D01; Tue, 29 Aug 2000 08:59:16 -0500 (CDT)
Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3])
	by ztxmail01.ztx.compaq.com (Postfix) with ESMTP
	id 0849724B1; Tue, 29 Aug 2000 08:59:16 -0500 (CDT)
Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM)
	id JAA0000703029; Tue, 29 Aug 2000 09:59:00 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008291359.JAA0000703029@anw.zk3.dec.com>
To: Thomas Narten <narten@raleigh.ibm.com>
Cc: ipng@sunroof.eng.sun.com
Subject: Re: W.G. Last Call on "Privacy Extensions for Stateless Address Autoconfiguration in IPv6s" 
In-reply-to: Your message of "Tue, 29 Aug 2000 07:08:29 EDT."
             <200008291108.HAA03452@hygro.adsl.duke.edu> 
Date: Tue, 29 Aug 2000 09:58:59 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Thomas,

>> This document discusses concerns associated with the embedding of
>> non-changing interface identifiers within IPv6 addresses and describes
>> optional extensions to stateless address autoconfiguration that can
>> help mitigate those concerns in environments where such concerns are
>> significant.
>
>Is the "optional" wording not strong enough?

Yes it is.  I was only getting clarification on section 4 paragraph that
said addr arch was possibly usurped and you fixed that too.

thanks
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Tue Aug 29 12:02:48 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7TJ18921486
	for ipng-dist; Tue, 29 Aug 2000 12:01:08 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7TJ0x621479
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 12:01:00 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03696
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 12:00:54 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA00831
	for <ipng@sunroof.eng.sun.com>; Tue, 29 Aug 2000 12:00:49 -0700 (PDT)
Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Aug 2000 12:01:10 -0700 (Pacific Daylight Time)
Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58)
	id <QA25NJKW>; Tue, 29 Aug 2000 12:01:08 -0700
Message-ID: <7695E2F6903F7A41961F8CF888D87EA85A3966@red-msg-06.redmond.corp.microsoft.com>
From: Richard Draves <richdr@microsoft.com>
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>,
   Christian Huitema
	 <huitema@microsoft.com>
Cc: "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
   IPng Working Group
	 <ipng@sunroof.eng.sun.com>
Subject: RE: When should mobile nodes use their care-of address, etc... 
Date: Tue, 29 Aug 2000 11:46:53 -0700
X-Mailer: Internet Mail Service (5.5.2651.58)
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

>    So if you believe the policy table mechanisms in the draft are too
>    inflexible for mobility, then you are free to invent & 
> implement more
>    powerful mechanisms.
>    
> => Will the draft go in the standard track or be published as 
> informational?
> In the first case you should not use this kind of answers, in 
> the second
> case at least two documents for the standard track (6to4 and 
> privacy IID)
> depend on your draft...

It is intended to be standards track.

I view the policy table in my draft to be a conceptual data structure, akin
to the conceptual data structures in the Neighbor Discovery RFC. (The draft
should say this more explicitly.) The policy table mechanism is doing two
things:
1. The rules and the default policy table together specify *default*
behavior. Implementations can achieve this default behavior in many ways; an
implementation might not have anything exactly like the draft's policy table
in it.
2. The policy table mechanism specifies a minimum level of flexibility in
configuration that we think is desirable. But this is a SHOULD; for example,
an implementation for a constrained environment might not be configurable at
all.

I hope this approach is OK for a standards track draft. I'm very happy to be
guided here by those with more IETF experience.

Continuing the Neighbor Discovery analogy: the ND spec talks about data
structures like a Neighbor Cache, Destination Cache, Prefix List, Default
Router List and uses these data structures to specify behavior. But in
practice, many implementations have more flexible & complicated data
structures internally, like a routing table. In the same way, your
implementation of address selection could have a more flexible configuration
mechanism than the simple policy tables in the draft.

This brings me to Christian's comment:

> May I observe that, in attempting to specify a source address 
> selection algorithm, the WG goes well beyond the traditional 
> IETF role, which is to focus on interoperability issues, not 
> implementations? I would expect such algorithms to evolve in 
> time, as we learn more on the subject. I would also expect 
> them to vary a lot depending on how much a particular station 
> knows about its environment, how far in the future it can 
> predict the application's behavior, what arbitration is made 
> between privacy and performance, etc. Rather than specify an 
> actual algorithm, the WG should be content with a list of 
> recommendations, in the form of "if you do this, expect that" 
> or "don't do X, because it will cause interoperability problem Y." 

The draft does try to strike a balance between requirements &
recommendations for implementations. There is a continuum. At one end, not
using a multicast or anycast address as a source address. At the other end,
using longest-matching-prefix to guess at a "good" source address for the
destination.

Issues like mismatched scope (can you use a link-local source to send to a
global destination, or global source to send to a link-local destination)
can certainly affect interoperability. For example, implementor A may decide
to always use the largest possible scope source address, on the grounds that
bigger scope is better. Implementator B may decide that mismatched scope is
bad and will never send such packets. Then A will be unable to open a TCP
connection to B's link-local address.

Choices of preferred vs. deprecated addresses, anonymous vs. public
addresses, home vs. care-of addresses probably aren't going to cause
interoperability problems. (Because the other guy can't tell what kind of
address you are using.) But these choices are important to achieving the
goals of other standards-track documents. For example, RFC 2462 says "new
communication should use a preferred address when possible". How does this
stipulation relate to scope consideration? etc. I think giving concrete
algorithmic guidance to implementors trying to make sense of all this is a
good thing - we'll end up with more useful implementations.

I am willing to relax the draft language for the source address selection
rules for mobility & privacy, so that those rules are more recommendations
and less requirements. (What do others think of this???) The
preferred/deprecated concept is pretty well understood and I view the
avoidance of deprecated addresses to be more of a requirement than a
recommendation.

Rich
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug 30 03:51:45 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7UAnx522105
	for ipng-dist; Wed, 30 Aug 2000 03:49:59 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7UAnj622097
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 03:49:45 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA11567
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 03:49:43 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26783
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 04:49:42 -0600 (MDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23426;
	Wed, 30 Aug 2000 06:49:41 -0400 (EDT)
Message-Id: <200008301049.GAA23426@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-07.txt
Date: Wed, 30 Aug 2000 06:49:41 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPNG Working Group of the IETF.

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-07.txt
	Pages		: 14
	Date		: 29-Aug-00
	
This document describes a protocol for asking an IPv6 node to supply
certain network information, such as its fully-qualified domain
name.  IPv6 implementation experience has shown that direct queries
for a DNS name are useful, and a direct query mechanism for other
information has been requested.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.txt

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-ipngwg-icmp-name-lookups-07.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000829112004.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipngwg-icmp-name-lookups-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000829112004.I-D@ietf.org>

--OtherAccess--

--NextPart--


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

From owner-ipng@sunroof.eng.sun.com Wed Aug 30 07:36:23 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7UEYTV22310
	for ipng-dist; Wed, 30 Aug 2000 07:34:29 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7UEYJ622303
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 07:34:20 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA06297;
	Wed, 30 Aug 2000 07:34:19 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20717;
	Wed, 30 Aug 2000 08:34:18 -0600 (MDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA26937;
	Wed, 30 Aug 2000 07:34:18 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7UEYGk23199;
	Wed, 30 Aug 2000 07:34:16 -0700
X-Virus-Scanned:  Wed, 30 Aug 2000 07:34:16 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from maxdialin15.iprg.nokia.com (205.226.20.245, claiming to be "spruce.iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpdnpbHdk; Wed, 30 Aug 2000 07:34:07 PDT
Message-Id: <4.3.2.7.2.20000830073023.0201aaa8@mailhost.iprg.nokia.com>
X-Sender: hinden@mailhost.iprg.nokia.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 30 Aug 2000 07:33:28 -0700
To: narten@raleigh.ibm.com, Erik.Nordmark@eng.sun.com
From: Bob Hinden <hinden@iprg.nokia.com>
Subject: Request to Advance "IPv6 Node Information Queries"
Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Erik, Thomas,

The chairs of the IP Next Generation working group, on behalf of the 
working group, request that the following document be published as an 
Proposed Standard:

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-07.txt
	Pages		: 14
	Date		: 29-Aug-00

A working group last call for this document was completed on August 16, 
2000.  The -07 version of the draft resolves issues raised during the last 
call.

Bob Hinden / Steve Deering
IPng Working Group Co-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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug 30 11:45:47 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7UIhqg22510
	for ipng-dist; Wed, 30 Aug 2000 11:43:52 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7UIhe622503
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 11:43:40 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA09812
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 11:43:39 -0700 (PDT)
From: Internet-Drafts@ietf.org
Received: from galactica.it (mail7.galactica.it [212.41.208.24] (may be forged))
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26253
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 11:43:38 -0700 (PDT)
Received: from mail pickup service by galactica.it with Microsoft SMTPSVC;
	 Wed, 30 Aug 2000 20:45:52 +0200
Received: from loki.ietf.org ([132.151.1.177]) by galactica.it  with Microsoft SMTPSVC(5.5.1877.447.44);
	 Wed, 30 Aug 2000 14:50:33 +0200
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA28248
	for ietf-123-outbound.07@ietf.org; Wed, 30 Aug 2000 07:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA28116
	for <all-ietf@loki.ietf.org>; Wed, 30 Aug 2000 06:49:43 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23426;
	Wed, 30 Aug 2000 06:49:41 -0400 (EDT)
Message-Id: <200008301049.GAA23426@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-07.txt
Date: Wed, 30 Aug 2000 06:49:41 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPNG Working Group of the IETF.

	Title		: IPv6 Node Information Queries
	Author(s)	: M. Crawford
	Filename	: draft-ietf-ipngwg-icmp-name-lookups-07.txt
	Pages		: 14
	Date		: 29-Aug-00
	
This document describes a protocol for asking an IPv6 node to supply
certain network information, such as its fully-qualified domain
name.  IPv6 implementation experience has shown that direct queries
for a DNS name are useful, and a direct query mechanism for other
information has been requested.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.txt

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-ipngwg-icmp-name-lookups-07.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:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000829112004.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipngwg-icmp-name-lookups-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000829112004.I-D@ietf.org>

--OtherAccess--

--NextPart--

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

From owner-ipng@sunroof.eng.sun.com Wed Aug 30 14:46:10 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7ULiLK22719
	for ipng-dist; Wed, 30 Aug 2000 14:44:21 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7ULiC622712
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 14:44:12 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA26413;
	Wed, 30 Aug 2000 14:44:11 -0700 (PDT)
Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11981;
	Wed, 30 Aug 2000 14:44:11 -0700 (PDT)
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA05809;
	Wed, 30 Aug 2000 14:44:11 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e7ULi7D07775;
	Wed, 30 Aug 2000 14:44:07 -0700
X-Virus-Scanned:  Wed, 30 Aug 2000 14:44:07 -0700 Nokia Silicon Valley Email Exploit Scanner
Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(WTS.12.69) smtpd7hVwVX; Wed, 30 Aug 2000 14:44:03 PDT
Message-ID: <39AD8026.4395DF11@iprg.nokia.com>
Date: Wed, 30 Aug 2000 14:44:06 -0700
From: "Charles E. Perkins" <charliep@iprg.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: IPng Working Group <ipng@sunroof.eng.sun.com>
CC: dhcp-v6@bucknell.edu, Jim Bound <bound@zk3.dec.com>,
   Mike Carney <Michael.Carney@eng.sun.com>
Subject: Reasons for dynamic IPv6 address allocation for DHCPv6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


Hello folks,

Some people on the new DHCPv6 design team seem to be taking the
viewpoint that managed IPv6 computers are going to be like desktops.
>From that perspective, it's O.K. to revise the server's centralized
IP address allocation policy and reboot the IPv6 computer whenever
one needs a new IP address for some reason.  Perhaps an exception
will be made to allow network prefix renumbering to occur without
rebooting.

However, it seems quite likely that the future Internet will
have a lot of highly configurable and mobile devices, for which
the current static address configuration schemes being suggested
will be inadequate.

Some of the problem seems to stem from current preference of
configuring all necessary client parameters at reboot time.
What happens when the DHCPv6 client wants to run a synchronized
application, and the server didn't give out the timeserver extension
when the client rebooted?

Why do we have to frame all application requirements in terms of
what happens when the client reboots?

This was a design goal for DHCPv6 -- to avoid tying all application
needs to boot-time configuration.  I am afraid that we're going back to
boot-time constraints.  It's a dark place, not healthy for mobile nodes.

Regarding address allocation, the choices (as I understand them),
are as follows:

1) Each computer will get an IPv6 address whenever it asks for
   it.  If it asks twice, it will get two addresses.

2) Each computer will get the same list of IPv6 addresses no
   matter how often it asks.

I _think_ that the proponents of (2) will require editing the
server database before a DHCPv6 client could get another (new) 
address.  This is being suggested as a matter of "simplicity".

As a strong proponent of (1), and by the way as a strong proponent
of highly reconfigurable embedded devices, I find this is a big 
step backwards from the existing DHCPv6 specification.

Please note that any installation which favors (2) can trivially
implement the appropriate policy even in the existing DHCPv6
specification.  The discussion is not whether (2) is a useful
model for network administration.  No one disputes that (2)
should be enabled by DHCPv6.  No, instead, the discussion is
whether (1) should even be allowed at all.  The proponents of
the supposed (in my opinion quite illusory) gain in simplicity
wish to control address allocation policy to the extent that  
that DHCPv6 clients can never deviate from the pre-ordained
list of addresses.  Perhaps it will be "allowed" for clients
to spoof new identities by representing themselves using new
client identifiers. 

I offer a possible look at future address allocation policy. 
This is, of course, speculative, given that we have not
evolved into the world of plentiful IPv6 addresses yet.

First, I point out that anonymous addresses should (typically)
be acquired and used once, by a single application, and not 
necessarily used again.  Any policy by which a host computer
is allocated a list of "anonymous addresses" by a DHCPv6 server,
and gets the same list over and over again, is slightly cracked,
again in my opinion.  Designing a whole new DHCPv6 address allocation
protocol for anonymous addresses certainly argues against any
supposed gain in "simplicity".  I think it is very likely that
anonymous addresses on administered links have to be requested by
the application at the time of execution, and not preallocated.
Furthermore, any such address should be returned once it has  
been used (thus it is a "releasable resource"), or else requested
with a short lifetime.

DHCPv6 will likely be used to provide IPv6 care-of addresses on
administered links.  A mobile node may need to get a care-of
address for each of its IPv6 home addresses, but we do not know
enough to suppose that it always has to get a care-of address
for each of its home addresses.  It may use the same care-of 
address for more than one home address, or it may not.  Sometimes
it will want to get a care-of address for only one of its addresses,
or two, or four, even if it might have 10 home addresses.  For
such a node to be constrained _by DHCPv6 protocol_ to always  
getting all of its care-of addresses from the server is highly
suspect, and (worse) may imply some sort of preconfiguration
of each mobile device at the DHCPv6 server.

These are examples that are known today.  In the future, there
will be more.  I almost hate to go into description, because 
after all the strife in DHCPv6 it could be I will be attacked as
a dreamer who just does not understand existing practice.  But 
damn the torpedoes and here I go.  We do not _know_ all the ways
that IPv6 addresses will be used.

During this discussion, please keep in mind that future applications
should be able to be dynamically loaded onto a host computer at any
time.  While many computers may not support such features, many
other computers will.  We should not have to design _two_ protocols
for the different kinds of computers that use IPv6 addresses.

I believe that IPv6 addresses will continue to embody a certain  
amount of context and identity (on behalf of the user).  Thus,
if an application wishes to create a separate context and avoid
association with another application running on the same network
node, the most natural thing will be for that application to  
configure a new IPv6 address.  If the link is a managed link, then
DHCPv6 has to provide for that.

Each new (or sporadically used) identity may have special features:
- security profile
- QoS 
- special routing requirements (e.g. routing header)
- remote profile management 
- separate billing

It's not the job of the network layer feature configuration
architect to limit these future choices.

Thus, I claim that the direction, which has been very strongly
encouraged by several DHCPv4 experts, towards eliminating IPv6
address configuration flexibility, is wrong.  I hope that this
note to the IPng working group will serve to raise the level of
discussion so that the impending disaster can be averted.

Lastly, I will mention that we can't tell the applications exactly
how they ought to call DHCPv6 in order to get new addresses,
because no one has yet designed the API.  However, it would
take a lot longer to get the API right, judging from the history
of other APIs in the IPng group.  That should not be a precondition
for getting the protocol ready for initial deployment.

Regards,
Charlie P.
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Wed Aug 30 15:37:02 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7UMZBv22783
	for ipng-dist; Wed, 30 Aug 2000 15:35:11 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7UMZ2622776
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 15:35:02 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA01623
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 15:35:02 -0700 (PDT)
Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15563
	for <ipng@sunroof.eng.sun.com>; Wed, 30 Aug 2000 16:35:01 -0600 (MDT)
Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345)
	id 05A4F58E1; Wed, 30 Aug 2000 18:35:01 -0400 (EDT)
Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3])
	by zmamail01.zma.compaq.com (Postfix) with ESMTP
	id ADE7D231D; Wed, 30 Aug 2000 18:35:00 -0400 (EDT)
Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM)
	id SAA0000000031; Wed, 30 Aug 2000 18:34:59 -0400 (EDT)
From: Jim Bound <bound@zk3.dec.com>
Message-Id: <200008302234.SAA0000000031@yquarry.zk3.dec.com>
X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol
To: "Charles E. Perkins" <charliep@iprg.nokia.com>
Cc: IPng Working Group <ipng@sunroof.eng.sun.com>, dhcp-v6@bucknell.edu,
   Jim Bound <bound@zk3.dec.com>, Mike Carney <Michael.Carney@eng.sun.com>
Subject: Re: Reasons for dynamic IPv6 address allocation for DHCPv6 
In-reply-to: Your message of "Wed, 30 Aug 2000 14:44:06 PDT."
             <39AD8026.4395DF11@iprg.nokia.com> 
Date: Wed, 30 Aug 2000 18:34:59 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

Charlie,

Reference Point:
--------------------------------
1) Each computer will get an IPv6 address whenever it asks for
   it.  If it asks twice, it will get two addresses.

2) Each computer will get the same list of IPv6 addresses no
   matter how often it asks.
---------------------------------

As you already know and for the record I fully agree with all your
"technical analysis" and also am a proponent of #1.   You have also clearly
articulated the reasoning why a different direction was selected in this
instance than DHCPv4.

Also what is very important architecturally as you stated, nothing in
dhcpv6 prevents #2 at all.

That being said it is also imperative we ship a spec by San Diego
meeting that many implementors feel comfortable writing code to and
showing up at our bake-offs at with running code in 2001.  Hats
off also to Francis Dupont and his team who have implemented this code
and that should be a positive light and message to this community as
Francis is one of our lead implementors for IPv6 for many years.

Also as editor, implementor, and WG member for the IPv6 base API we all know
APIs don't get done fast when you try to cover the future (e.g. Scoping,
Anycast Effect) and to hold up any protocol for an API is just plain bad
engineering trade-off judgement.  We need to build the protocol and the
API will come.  Or look at the IPv6 Advanced API that is taking some
time too.  Not only that but wearing my product engineer hat it is very
bad when you keep changing the API in an emerging market which we have done
in IPv6 and we have mail from ISVs now that told us either stop or we
give up on IPv6.  So premature APIs are very dangerous in the market
too.  

I think your mail should be part of the input to tomorrow's design interim
meeting which I have the highest hopes for thorough and par excellence
technical and architectural discussion will take place.  Ralph Droms has
done a good job putting together the agenda and is still collecting
input and also the DHCPv4 implementors are reading the drafts.  This is
all goodness for IPv6 as I think many are totally convinced now that
Stateless is not the only Plug N Play solution for IPv6 the market will
want and need and my favorite metric "pay for".  That in of itself has been 
a long hard battle in addition to building the protocol.  

I think it a good technical challenge to DHCPv6 for the folks who have 
lived with DHCPv4 implementations on the street, built them, or taught and
configured them to ask the basic question of dhcpv6, why does the
protocol leave any of the models inherent to DHCPv4.

Also this protocol cannot be driven only by client/sever computing as
was DHCPv4.  I will not restate what you said so well but IPv6 and the
Internet are about a lot more than client desktops, servers, and routers
but about the Internet networking fabric that has evolved beyond any of the
Pioneers expectations.  DHCPv6 technically has to be extensibile and
support the future needs of Mobile and Wireless devices where ever they
may roam :-----).

Talk to you at the meeting tomorrow.

regards,
/jim
--------------------------------------------------------------------
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
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 31 09:37:54 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7VGaR823251
	for ipng-dist; Thu, 31 Aug 2000 09:36:27 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7VGaD623242
	for <ipng@sunroof.eng.sun.com>; Thu, 31 Aug 2000 09:36:13 -0700 (PDT)
Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA12513
	for <ipng@sunroof.eng.sun.com>; Thu, 31 Aug 2000 09:36:12 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09115
	for <ipng@sunroof.eng.sun.com>; Thu, 31 Aug 2000 09:36:11 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09234;
	Thu, 31 Aug 2000 12:36:10 -0400 (EDT)
Message-Id: <200008311636.MAA09234@ietf.org>
To: IETF-Announce: ;
Cc: ipng@sunroof.eng.sun.com
From: The IESG <iesg-secretary@ietf.org>
SUBJECT: Last Call: IPv6 Node Information Queries to Proposed Standard
Reply-to: iesg@ietf.org
Date: Thu, 31 Aug 2000 12:36:10 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk


The IESG has received a request from the IPNG Working Group to consider
IPv6 Node Information Queries
<draft-ietf-ipngwg-icmp-name-lookups-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by September 13, 2000.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-07.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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

From owner-ipng@sunroof.eng.sun.com Thu Aug 31 11:50:40 2000
Received: (from majordomo@localhost)
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) id e7VIn3m23411
	for ipng-dist; Thu, 31 Aug 2000 11:49:03 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
	by sunroof.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e7VImn623404
	for <ipng@sunroof.eng.sun.com>; Thu, 31 Aug 2000 11:48:49 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA23423
	for <ipng@sunroof.eng.sun.com>; Thu, 31 Aug 2000 11:48:48 -0700 (PDT)
Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168])
	by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07225
	for <ipng@sunroof.eng.sun.com>; Thu, 31 Aug 2000 12:48:47 -0600 (MDT)
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA04429;
        Thu, 31 Aug 2000 14:48:45 -0400 (EDT)
Message-Id: <200008311848.OAA04429@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: iesg@ietf.org
cc: ipng@sunroof.eng.sun.com
Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard 
In-reply-to: Your message of "Thu, 31 Aug 2000 12:36:10 EDT."
             <200008311636.MAA09234@ietf.org> 
X-SUBJECT-MSG-FROM: The IESG <iesg-secretary@ietf.org> 
Date: Thu, 31 Aug 2000 14:48:45 -0400
Sender: owner-ipng@sunroof.eng.sun.com
Precedence: bulk

This proposal opens up a huge can of worms which might be better left closed.

A host can have multiple interfaces, mutiple addresses on an interface,
multiple interfaces with the same address, multiple domain names for
an address, and there can also be multiple addresses for a domain.  
A single domain can apply to multiple hosts, either via multiple addresses
or via a single address and an IP fanout device.  A host inherently
knows about its interfaces and the addresses assigned to them, but the 
relationship between DNS names and addresses is maintained elsewhere.
So the whole notion of "a node's domain name[s]" gets pretty sticky, 
even if you restrict that query to the names corresponding to a single 
IP address.  

My biggest concern about this proposal is that it doesn't specify the
purposes for which this service can be used.  To put it another way,
what services can rely on this information, and what services are 
allowed to break if the result from the ICMPv6 query doesn't correspond 
to what can be obtained from DNS (or to what applications running on 
that host believe)?  

For instance, might an application assume that if it obtains multiple
addresses for a host using this service that it can communicate with
an application on that host using any of those addresses ?
(which would fail given the quite common practice of virtual hosting)
or if it obtains multiple domain names for an address, can an application
assume that the domain names are equivalent?  (they're not, because either
of those domain names could also reach other hosts, and the two sets of
hosts might not be the same)

There should be only one authoritative source of the binding betweeen 
a DNS name and any addresses associated with that name, and it should
probably be DNS.   The notion that "sometimes DNS is right, and sometimes
the host is right" makes it hard to write code that behaves reliably.

Another concern I have is that this proposal seems to push DNS names 
into a lower layer of the protocol stack and thereby embeds them 
more deeply in the Internet architecture.  I believe it is highly 
desirable to keep these as completely separate layers.  The
separation of function between IP and DNS allows us to evolve each
of them separately, even to the point of replacing IP (which we
are doing) or providing alternate lookup services to DNS (which
is necessary if we want those lookup services to work efficiently)
The separation also allows problems with IP networks and/or 
applications to be diagnosed separately from DNS - it allows us
to debug such problems with the DNS layer out of the picture.

On a different level this proposal exposes a conflict between various 
autoconfiguration architectures which has been brewing for some time - 
does the host assert its name and/or address to the network or does the 
network tell the host its name and/or address?  It does this by creating
an alternate way to find a name-to-address bindings when in the
past the only publically available source of such information 
(and hence, the assumed authority for such information) was DNS.
It would be good to sort out this conflict, because sorting this out
is needed before autoconfiguration can really work effectively on a large
scale.  But sorting this out is probably needed before people start
building things which depend on this ICMPv6 service.  And sorting this
issue out probably also means answering the question of what is a 
reasonable lifetime for the binding between a host and an IP address.  
These will not be easy questions to answer, particularly because people's 
assumptions about what is reasonable (and where to distribute the pain 
of changing these things) vary widely.  But IMHO we need to answer
them before we start embedding DNS names more deeply into network
stacks, and especially before we start relying on this service.

There's also a security problem with defining a means by which hosts 
can be expected to expose information about their DNS names, the 
addresses they use, the networks they are on, etc.    This is yet
another source of information that would need to be filtered by
networks that didn't want to expose such information to external sites.


In a nutshell, my recommendations are:

- document the intended use (diagnostics?) and clearly specify
  that the authoritative source of these mappings is in DNS

- make this Experimental rather than Proposed

- document the security issues wrt inappropriate exposure
  
- require that implementations be able to turn off this feature,
  and that it be disabled by default.  actually hosts should probably
  require explicit configuration regarding which domain names and
  which addresses to advertise by this method.

Keith
--------------------------------------------------------------------
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
--------------------------------------------------------------------