From owner-ipng  Tue Aug  1 00:45:11 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29029; Tue, 1 Aug 95 00:45:11 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29023; Tue, 1 Aug 95 00:45:02 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA10954; Tue, 1 Aug 1995 00:34:21 -0700
Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM)
	id AAA06803; Tue, 1 Aug 1995 00:34:21 -0700
Received: from dxcoms.cern.ch by dxmint.cern.ch
	id AA22040; Tue, 1 Aug 1995 09:34:19 +0200
Received: by dxcoms.cern.ch
	id AA19332; Tue, 1 Aug 1995 09:34:17 +0200
Message-Id: <9508010734.AA19332@dxcoms.cern.ch>
Subject: (IPng 452) Re: Ethertype and multicast filtering info
To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Date: Tue, 1 Aug 1995 09:34:16 +0200 (MET DST)
From: "Brian Carpenter   CERN-CN" <brian@dxcoms.cern.ch>
In-Reply-To: <9507312236.AA10095@angelo.amd.com> from "Dave Roberts" at Jul 31, 95 03:36:56 pm
X-Mailer: ELM [version 2.4 PL23 DXCOMS1]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Dave,

> In the meeting, there was a comment (by Brian Carpenter, I believe)
> that PCs should simply get better hardware and that we'll grow out of
> this problem.  This is a dangerous sentiment to espouse as a solution
> to this problem.  As I said above, there is no distinction between
> controllers used in PCs and workstations.

As I recall the point came up because somebody (Geert-Jan?)
proposed reverting to broadcast for neighbour discovery.

I don't know what I said, but I hope this is what I meant:

 1. Don't design IPv6 discovery to be constrained by the hardware
    of the mid-1990's.

 2. Older PCs have trouble with both broadcast and multicast
    so reverting to the broadcast ARP model doesn't help.

If vendors are shipping interfaces that fall over when more than
a few multicast groups are in use, they will get egg on their
faces anyway, independently of IPv6 discovery.

   Brian
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 01:21:10 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29073; Tue, 1 Aug 95 01:21:10 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29067; Tue, 1 Aug 95 01:20:57 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12353; Tue, 1 Aug 1995 01:10:17 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id BAA09413; Tue, 1 Aug 1995 01:09:57 -0700
Message-Id: <m0sdCXf-00013rC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 453) Re: reversal of source routes
To: perk@watson.ibm.com (Charlie Perkins)
Date: Tue, 1 Aug 1995 09:19:10 +0100 (BST)
Cc: rstevens@noao.edu, ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9507311700.AA40781@hawpub1.watson.ibm.com> from "Charlie Perkins" at Jul 31, 95 01:00:19 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> security consequences of requiring the reversal of
> source routes.  I thought that there was agreement that
> the current draft _purposefully_ omitted the requirement
> that source routes be reversed, in order to simplify
> implementations and eliminate the security problems.

Reversing a source route is not hard. Solving the security implications
is. I don't think I could feel comfortable about shipping an IPv6 configuration
that used source routes until all the security parts of IPv6 are proven and
in place - which isn't currently the case.

Once the IPv6 authentication is felt complete, working and in use the whole
problem about source routes and impersonation goes way, although the issue of
routing policy violating is not

For example there is an FTP client that loose source routes IPv4 packets
via finland that is spreading through parts of the UK academic community. This
is because the UK->US academic link is bad and the route via finland is better
- but it is unlikely to be what the networking powers that be who paid
for things like the finland->US link want.

Trying to scan a source route list for a routing policy violation will be
hard.

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 09:44:55 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29290; Tue, 1 Aug 95 09:44:55 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29284; Tue, 1 Aug 95 09:44:47 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13989; Tue, 1 Aug 1995 09:34:01 -0700
Received: from amdext.amd.com by mercury.Sun.COM (Sun.COM)
	id JAA09015; Tue, 1 Aug 1995 09:33:56 -0700
Received: from amdint.amd.com by amdext.amd.com with SMTP id AA02017
  (5.67a/IDA-1.5+AMD for <ipng@sunroof.eng.sun.com>); Tue, 1 Aug 1995 09:33:52 -0700
Received: from brahms.amd.com by amdint.amd.com with SMTP id AA06076
  (5.67a/IDA-1.5+AMD); Tue, 1 Aug 1995 09:33:50 -0700
Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18)
	id AA00713; Tue, 1 Aug 95 09:33:47 PDT
Received: by angelo.amd.com (4.1/AMDC-1.18)
	id AA24134; Tue, 1 Aug 95 09:33:46 PDT
From: David.Roberts@amd.com (Dave Roberts)
Message-Id: <9508011633.AA24134@angelo.amd.com>
Subject: (IPng 454) Re:  Ethertype and multicast filtering info
To: rstevens@noao.edu
Date: Tue, 1 Aug 1995 09:33:45 -0700 (PDT)
Cc: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List)
In-Reply-To: <9508010058.AA01196@gemini.tuc.noao.edu> from "Richard Stevens" at Jul 31, 95 05:58:35 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> When you say "software checks" do you mean software on the card, or are
> you referring to the driver software?  I'd guess you mean driver software
> (I've been through the Lance driver) but just wanted to check if there's
> still more going on within the interface itself.

The driver.  It could be running on the card if you have a card with a
coprocessor or on the host.

Dave Roberts
david.roberts@amd.com


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 10:05:22 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29314; Tue, 1 Aug 95 10:05:22 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29308; Tue, 1 Aug 95 10:05:14 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16862; Tue, 1 Aug 1995 09:54:22 -0700
Received: from amdext.amd.com by mercury.Sun.COM (Sun.COM)
	id JAA14528; Tue, 1 Aug 1995 09:54:14 -0700
Received: from amdint.amd.com by amdext.amd.com with SMTP id AA05928
  (5.67a/IDA-1.5+AMD for <ipng@sunroof.eng.sun.com>); Tue, 1 Aug 1995 09:54:09 -0700
Received: from brahms.amd.com by amdint.amd.com with SMTP id AA13378
  (5.67a/IDA-1.5+AMD); Tue, 1 Aug 1995 09:54:05 -0700
Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18)
	id AA02307; Tue, 1 Aug 95 09:54:02 PDT
Received: by angelo.amd.com (4.1/AMDC-1.18)
	id AA24638; Tue, 1 Aug 95 09:54:00 PDT
From: David.Roberts@amd.com (Dave Roberts)
Message-Id: <9508011654.AA24638@angelo.amd.com>
Subject: (IPng 455) Re:  Ethertype and multicast filtering info
To: stripes@va.pubnix.com (Josh M. Osborne)
Date: Tue, 1 Aug 1995 09:54:00 -0700 (PDT)
Cc: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List)
In-Reply-To: <XAA14631.199508010306@garotte.va.pubnix.com> from "Josh M. Osborne" at Jul 31, 95 11:06:44 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> While I agree that this is a dangerous sentiment I disagree with your
> assessment.  Much of the problem is caused by the amount of time it
> takes to process the ethernet intrrupt and decide if the multicast
> packet is "intresting".  In genneral PC's are fairly slow to do this,
> and some workstations are reasonable fast, and most embeded envirments
> can be *very* fast.  In particular a SPARC V9 CPU can take an intrrupt
> in a very small number of cycles most of the time, and your componies
> AMD29xx0 CPU can take an intrrupt *very* fast (I beleve it can be
> doing useful work as little as 2 cycles after the intrrupt happens,
> and could walk a reasonably sized multicast table before a protected
> mode 80486 CPU managed to save its entire internal processor state and
> take an intrrupt (which I think takes on the order of 200 cycles - many
> of them memory cycles).

Yes, but... again, you've got an installed base problem.  As much as I
might like 29xx0's to take over the world and be the main processor of
choice for running IPv6, I don't think that will happen any time soon.
Saying that (paraphrasing), "It's only a problem on PCs," is a not a
good way to pave the way for IPv6 adoption.  If IPv6 craters on PC's,
I don't see a lot of organizations moving toward IPv6 given that most
every organization probably has at least a few PCs that are attached
to the net.

As many people (you included) have pointed out, there are solutions
that help and the chips can be made better.  I didn't mean to imply
that the issue was unsolvable, just that if we aren't careful we could
have problems on the current chips, of which the industry will ship
about 10+ million this year.  What I'd like is for people to simply be
congnizant of the problem, try to create a solution which is crafted
in a forward looking manner yet takes into consideration the
limitations of the current installed base of hardware.  In short, we
can nudge the industry in the right direction but we can't cause all
the current hardware to fall over.

> One last thing, if the ethernet vendors saw a need to make fast
> multicast address recognisers I think some inexpensiave solutions could
> be found.  For instance the MAC addresses don't need to be stored in a
> CAM.  The ethenet chip can go about storing the packet in the buffer
> it would normally store a packet, and sequentally compair the MAC on
> that packet to a list of MACs it has.  Since each ethernet packet is
> (I beleve) a minimum of 64 bytes long, at 1 bit per 100ns you have
> 4640ns to do a table walk (sequental - or some form of tree), that
> is assuming the MAC is the first 6 bytes, I reall don't remember
> exactly how much of the first 64bytes you need to read.  There is
> also a mandated dead time between packets...
> 
> Of corse that all depends on the ethernet venders deciding there is
> a need for such things, and it may change the cost from $3/ea to $6/ea,
> (assuming they think the volume will stay the same) which will change
> the standalone cost from $75 to $150, but that still may be affordable
> enough to people.  Or not.

Right.  As you point out, there are ways to get better.  But again,
looking at the adoption of IPv6, if we, IETF, put out a solution that
causes all (okay, a significant portion) of your *current* hardware to
crash or perform poorly, then we've got a problem.  Your choices are,
stick with IPv4 (or some other protocol) or throw out all the
offending adapters.  Taking the path of least resistance (especially
if you've already got IPv4 deployed, configured and working), you
won't adopt IPv6.  That, IMHO, is not what we want.

Dave Roberts
david.roberts@amd.com


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 10:16:07 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29337; Tue, 1 Aug 95 10:16:07 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29331; Tue, 1 Aug 95 10:15:58 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA18848; Tue, 1 Aug 1995 10:05:13 -0700
Received: from amdext.amd.com by mercury.Sun.COM (Sun.COM)
	id KAA17637; Tue, 1 Aug 1995 10:04:56 -0700
Received: from amdint.amd.com by amdext.amd.com with SMTP id AA07820
  (5.67a/IDA-1.5+AMD for <ipng@sunroof.eng.sun.com>); Tue, 1 Aug 1995 10:04:53 -0700
Received: from brahms.amd.com by amdint.amd.com with SMTP id AA17124
  (5.67a/IDA-1.5+AMD); Tue, 1 Aug 1995 10:04:52 -0700
Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18)
	id AA03510; Tue, 1 Aug 95 10:04:44 PDT
Received: by angelo.amd.com (4.1/AMDC-1.18)
	id AA25137; Tue, 1 Aug 95 10:04:42 PDT
From: David.Roberts@amd.com (Dave Roberts)
Message-Id: <9508011704.AA25137@angelo.amd.com>
Subject: (IPng 456) Re: Ethertype and multicast filtering info
To: brian@dxcoms.cern.ch (Brian Carpenter   CERN-CN)
Date: Tue, 1 Aug 1995 10:04:41 -0700 (PDT)
Cc: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List)
In-Reply-To: <9508010734.AA19332@dxcoms.cern.ch> from "Brian Carpenter   CERN-CN" at Aug 1, 95 09:34:16 am
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Sorry, Brian, I didn't mean to finger point.  I was just trying to
give a handle for people to remember the conversation.  Futher, I'll
say that I agree with a lot of your sentiments, just not as strongly.

> > In the meeting, there was a comment (by Brian Carpenter, I believe)
> > that PCs should simply get better hardware and that we'll grow out of
> > this problem.  This is a dangerous sentiment to espouse as a solution
> > to this problem.  As I said above, there is no distinction between
> > controllers used in PCs and workstations.
> 
> As I recall the point came up because somebody (Geert-Jan?)
> proposed reverting to broadcast for neighbour discovery.
> 
> I don't know what I said, but I hope this is what I meant:
> 
>  1. Don't design IPv6 discovery to be constrained by the hardware
>     of the mid-1990's.

Correct, but it must take consideration of the hardware in the
mid-1990s.  Assuming that we want IPv6 to start getting deployed, it
would be *bad* if it caused major problems on current hardware.  If it
just causes minor problems, that acceptable.  That is, people can
deploy it, but then they'll move to the new hardware willingly at
their own pace.

>  2. Older PCs have trouble with both broadcast and multicast
>     so reverting to the broadcast ARP model doesn't help.

I'm not sure what you mean.  Broadcast is just fine for neighbor
discovery as long as you don't also put your multimedia streams on it.
Multicast *would be* just fine for neighbor discovery if high
bandwidth streams weren't also going to use it and cause collisions in
the current hash filtering schemes.

> If vendors are shipping interfaces that fall over when more than
> a few multicast groups are in use, they will get egg on their
> faces anyway, independently of IPv6 discovery.

The problem is, just about everybody does it that way currently.  Some
support more, some support less, but all the chips basically have the
same problem.  If it was one vendor with very small market share then
I wouldn't have a problem, but that's not the case.

An again, I'm not saying we definitely have a problem, only that we
have a potential issue that we need to manage as we go forward.

Dave Roberts
david.roberts@amd.com

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 12:35:11 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29465; Tue, 1 Aug 95 12:35:11 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29459; Tue, 1 Aug 95 12:35:02 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA09992; Tue, 1 Aug 1995 12:24:12 -0700
Received: from aero.org by mercury.Sun.COM (Sun.COM)
	id MAA23735; Tue, 1 Aug 1995 12:24:06 -0700
Received: from antares.aero.org ([130.221.192.46]) by aero.org with SMTP id <111115-2>; Tue, 1 Aug 1995 12:23:33 -0700
Received: from anpiel.aero.org by antares.aero.org (4.1/AMS-1.0)
	id AA02621 for alan.lloyd@datacraft.com.au; Tue, 1 Aug 95 12:23:23 PDT
To: Alan.Lloyd@datacraft.com.au
Cc: <deering@parc.xerox.com>, <ipng@sunroof.Eng.Sun.COM>
Subject: (IPng 457) Re: Lixia's study group 
In-Reply-To: Your message of "Tue, 01 Aug 1995 03:40:28 PDT."
             <vines.p659+afK5kA@dcthq2.datacraft.com.au> 
Date: 	Tue, 1 Aug 1995 12:23:21 -0700
From: "Mike O'Brien" <obrien@antares.aero.org>
Message-Id: <95Aug1.122333pdt.111115-2@aero.org>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Alan Lloyd says:
> ps. I am still not sure how we deal with unowned addresses. something,
> somewhere has to define, administer and manage them.
>
> Is this a job for the Pope?

You know, I like it.  There's historical precedent, after all: he carved
up South America on request.  Why not the Domain Name space?
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 12:37:44 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29477; Tue, 1 Aug 95 12:37:44 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29471; Tue, 1 Aug 95 12:37:36 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA10284; Tue, 1 Aug 1995 12:26:54 -0700
Received: from aero.org by venus.Sun.COM (Sun.COM)
	id MAA15129; Tue, 1 Aug 1995 12:26:53 -0700
Received: from antares.aero.org ([130.221.192.46]) by aero.org with SMTP id <111107-2>; Tue, 1 Aug 1995 12:25:32 -0700
Received: from anpiel.aero.org by antares.aero.org (4.1/AMS-1.0)
	id AA02640 for alan.lloyd@datacraft.com.au; Tue, 1 Aug 95 12:24:46 PDT
To: Alan.Lloyd@datacraft.com.au
Cc: <deering@parc.xerox.com>, <ipng@sunroof.Eng.Sun.COM>
Subject: (IPng 458) Re: Lixia's study group 
In-Reply-To: Your message of "Tue, 01 Aug 1995 03:40:28 PDT."
             <vines.p659+afK5kA@dcthq2.datacraft.com.au> 
Date: 	Tue, 1 Aug 1995 12:24:44 -0700
From: "Mike O'Brien" <obrien@antares.aero.org>
Message-Id: <95Aug1.122532pdt.111107-2@aero.org>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Why not the Domain Name space?

Oops, sorry, wrong flame war.  Still, the idea has its merits.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 14:52:46 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29595; Tue, 1 Aug 95 14:52:46 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29589; Tue, 1 Aug 95 14:52:38 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00682; Tue, 1 Aug 1995 14:41:56 -0700
Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM)
	id OAA21238; Tue, 1 Aug 1995 14:41:54 -0700
From: Alan.Lloyd@datacraft.com.au
Received: from datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50)
	id AA25509; Wed, 2 Aug 1995 07:41:37 +1000 (from Alan.Lloyd@datacraft.com.au)
Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef)
	id AA26942; Wed, 2 Aug 95 07:21:18 +1000
Received: by dcthq2.datacraft.com.au; Wed, 2 Aug 95 7:46:06 +1100
Date: Wed, 2 Aug 95 7:10:50 AUS
Message-Id: <vines.p659+A8d5kA@dcthq2.datacraft.com.au>
X-Priority: 3 (Normal)
To: <obrien@antares.aero.org>
Cc: <ipng@sunroof.Eng.Sun.COM>
Subject: (IPng 459) Re: Lixia's study group
X-Incognito-Sn: 578
X-Incognito-Format: VERSION=2.01a ENCRYPTED=NO
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Addresses
on this one re address administration (please yawn now).

I dont mind national registries because nationally we manage telephone 
numbers, X.121 addresses, Vehicle Licence plates, Taxfile(DSS)No's, Radio/TV 
spectrums, X.400 addresses, Object Ids, NSAPs, X.500 Distinguished Names, 
Certfication Authorties,Postage Stamps, Our Currency, Company Numbers, 
Aircraft numbers, City- Town and Street names and numbers,
territorial water, fish and fruit fly. As well as cane toads, kangaroos, 
rabbits and duck billed platypus.

Some of the above are managed better than others

Now if one takes the responsibilty of designing global protocols, networks, 
mail systems, directory systems, management systems and security. One also 
takes on the responsibility for administering all the associated addresses, 
body part types, OIDs, name forms, etc, etc. Or one can delegate it to (for 
example :-) national authorities. I am sure that in Australia we can find a 
few national bodies that will do this.

If the format of IP6 addresses was for example:

Top bits:	 010 IANA assigned addresses
	         011 ISO/ITU assigned addresses

Next Five bits	Regional Registry ID or Global Registry

Next Four bits  Format Id
		0 = IP6 compatable IP4
		1 = DCC + IP6 provider/subscriber *regional registries only
		2 = DCC + IP6 with embedded E.164           ditto
		3 = DCC + IP6 with embedded 802.x           ditto
                1 = ICD + IP6 provider/subscriber * global registry only
                2 = ICD + IP6 with embedded E.164       ditto
		3 = ICD + IP6 with embedded 802.x       ditto
                4,5 = IP6 with embedded E.164 * any registry
		5,6 = IP6 with embedded 802.x      ditto
		7-F = IP6 provider / subscriber    ditto

The rest as defined above.
ie a DCC, and ICD or a provider.

Yes I know this is not perfect and does have wharts, but so do I and the 
world is not a perfect place. Also the bits above should not be seen as 
definative, just a few ideas that are supported by whats in place.

One thing we cannot do is wait for all the ideals and supporting mechanisms 
are in place to automatically and dynamically reconfigure the whole planet in 
a nanosecond.

Finally I think Tony Li and Yakov should be more positive about saying owning 
addresses is fatal. After all, if Chirac can say nuclear bombs are good for 
us (now there's market vision) owning addresses cant be that bad.

Can we have a national poll on this? or a quick chant. HMMMMMMMMMMMM

Amen
Regards Alan@Oz
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 15:33:27 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29666; Tue, 1 Aug 95 15:33:27 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29646; Tue, 1 Aug 95 15:24:44 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06414; Tue, 1 Aug 1995 15:13:49 -0700
Received: from CU.NIH.GOV by mercury.Sun.COM (Sun.COM)
	id PAA28842; Tue, 1 Aug 1995 15:13:47 -0700
Message-Id: <199508012213.PAA28842@mercury.Sun.COM>
To: David.Roberts@amd.com
Cc: ipng@sunroof.Eng.Sun.COM
From: "Roger Fajman" <RAF@CU.NIH.GOV>
Date:     Tue, 01 Aug 1995  18:10:41 EDT
Subject: (IPng 460) Re: Ethertype and multicast filtering info
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> >  2. Older PCs have trouble with both broadcast and multicast
> >     so reverting to the broadcast ARP model doesn't help.
>
> I'm not sure what you mean.  Broadcast is just fine for neighbor
> discovery as long as you don't also put your multimedia streams on it.
> Multicast *would be* just fine for neighbor discovery if high
> bandwidth streams weren't also going to use it and cause collisions in
> the current hash filtering schemes.

AppleTalk Phase II uses multicast instead of broadcast.  Has anyone
noticed problems with MBONE multicasts interfering with Macintoshes?

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 15:59:44 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29721; Tue, 1 Aug 95 15:59:44 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA29699; Tue, 1 Aug 95 15:56:14 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11089; Tue, 1 Aug 1995 15:45:32 -0700
Received: from amdext.amd.com by mercury.Sun.COM (Sun.COM)
	id PAA05828; Tue, 1 Aug 1995 15:45:31 -0700
Received: from amdint.amd.com by amdext.amd.com with SMTP id AA00325
  (5.67a/IDA-1.5+AMD for <ipng@sunroof.eng.sun.com>); Tue, 1 Aug 1995 15:45:29 -0700
Received: from brahms.amd.com by amdint.amd.com with SMTP id AA25885
  (5.67a/IDA-1.5+AMD); Tue, 1 Aug 1995 15:45:29 -0700
Received: from angelo.amd.com by brahms.amd.com (4.1/AMDSN-1.18)
	id AA25799; Tue, 1 Aug 95 15:45:28 PDT
Received: by angelo.amd.com (4.1/AMDC-1.18)
	id AA05837; Tue, 1 Aug 95 15:45:27 PDT
From: David.Roberts@amd.com (Dave Roberts)
Message-Id: <9508012245.AA05837@angelo.amd.com>
Subject: (IPng 461) Re: Ethertype and multicast filtering info
To: RAF@CU.NIH.GOV (Roger Fajman)
Date: Tue, 1 Aug 1995 15:45:27 -0700 (PDT)
Cc: ipng@sunroof.Eng.Sun.COM (IPNG Mailing List)
In-Reply-To: <199508012213.PAA28842@mercury.Sun.COM> from "Roger Fajman" at Aug 1, 95 06:10:41 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> > >  2. Older PCs have trouble with both broadcast and multicast
> > >     so reverting to the broadcast ARP model doesn't help.
> >
> > I'm not sure what you mean.  Broadcast is just fine for neighbor
> > discovery as long as you don't also put your multimedia streams on it.
> > Multicast *would be* just fine for neighbor discovery if high
> > bandwidth streams weren't also going to use it and cause collisions in
> > the current hash filtering schemes.
> 
> AppleTalk Phase II uses multicast instead of broadcast.  Has anyone
> noticed problems with MBONE multicasts interfering with Macintoshes?

Ah, good question!  The only problem is that current MBONE usage
hasn't been all that great up till now (at least relative to what I'm
anticipating real-time streaming traffic could be in the next few
years).  Also, isn't current MBONE bandwidth pretty constrained by the
source in order not to occupy a significant amount of the bandwidth on
the current WAN links?  The point is, even if there were collisions
happening on an individual Ethernet segment, current MBONE traffic
might not be representative of the high-bandwidth streams that we
expect to see in an IPv6 network a few years from now.

Dave Roberts
david.roberts@amd.com

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 21:08:35 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00335; Tue, 1 Aug 95 21:08:35 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00329; Tue, 1 Aug 95 21:08:26 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12755; Tue, 1 Aug 1995 20:57:42 -0700
Received: from ns.crynwr.com by mercury.Sun.COM (Sun.COM)
	id UAA19971; Tue, 1 Aug 1995 20:57:40 -0700
Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4)
	id m0sdUvq-000H97C; Tue, 1 Aug 95 23:57 EDT
Message-Id: <m0sdUvq-000H97C@ns.crynwr.com>
Date: Tue, 1 Aug 95 23:57 EDT
From: nelson@crynwr.com (Russell Nelson)
To: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508011654.AA24638@angelo.amd.com> (David.Roberts@amd.com)
Subject: (IPng 462) Re: Ethertype and multicast filtering info
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   From: David.Roberts@amd.com (Dave Roberts)
   Date: Tue, 1 Aug 1995 09:54:00 -0700 (PDT)

   What I'd like is for people to simply be congnizant of the problem,
   try to create a solution which is crafted in a forward looking
   manner yet takes into consideration the limitations of the current
   installed base of hardware.

I agree with this.

   In short, we can nudge the industry in the right direction but we
   can't cause all the current hardware to fall over.

But I don't agree that it will necessarily cause your hardware to fall
over.  DOOM 1.1 broadcasts went out at 100 packets/second.  Nobody
noticed until some WAN links got overloaded.

As long as you don't have a permanent situation where the multimedia
multicast group Ethernet address falls into the same hash bucket as
the IPNG multicasts, you'll have a <2% probability of something
happening that no one noticed.

Turn it around the other way: many machines have enough horsepower to
run DOOM and still receive and process 100 packets/second.

-- 
-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | Describe the God you don't
Potsdam, NY 13676 | believe in, and I won't believe in that God either.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 23:10:26 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00426; Tue, 1 Aug 95 23:10:26 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00420; Tue, 1 Aug 95 23:10:18 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA18804; Tue, 1 Aug 1995 22:59:36 -0700
Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM)
	id WAA00426; Tue, 1 Aug 1995 22:59:35 -0700
Received: from dxcoms.cern.ch by dxmint.cern.ch
	id AA08466; Wed, 2 Aug 1995 07:59:34 +0200
Received: by dxcoms.cern.ch
	id AA22438; Wed, 2 Aug 1995 07:59:32 +0200
Message-Id: <9508020559.AA22438@dxcoms.cern.ch>
Subject: (IPng 463) Re: Ethertype and multicast filtering info
To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Date: Wed, 2 Aug 1995 07:59:32 +0200 (MET DST)
From: "Brian Carpenter   CERN-CN" <brian@dxcoms.cern.ch>
In-Reply-To: <m0sdUvq-000H97C@ns.crynwr.com> from "Russell Nelson" at Aug 1, 95 11:57:00 pm
X-Mailer: ELM [version 2.4 PL23 DXCOMS1]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Russ,

> But I don't agree that it will necessarily cause your hardware to fall
> over.  DOOM 1.1 broadcasts went out at 100 packets/second.  Nobody
> noticed until some WAN links got overloaded.

Are you kidding??

Any system that fires up doom, xpilot or any similar
<expletive deleted> around here gets cut off real quick. People
don't notice because they don't monitor, but 100pps broadcast
is a performance hit on every other host. This is just as
true in a dentist's office as on a big network.

Re-read section 5.12 of RFC 1726. I thought we had buried
this discussion last year.

  Brian
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  1 23:25:51 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00455; Tue, 1 Aug 95 23:25:51 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00449; Tue, 1 Aug 95 23:25:42 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19781; Tue, 1 Aug 1995 23:15:00 -0700
Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM)
	id XAA01689; Tue, 1 Aug 1995 23:14:59 -0700
Received: from dxcoms.cern.ch by dxmint.cern.ch
	id AA10773; Wed, 2 Aug 1995 08:14:45 +0200
Received: by dxcoms.cern.ch
	id AA22842; Wed, 2 Aug 1995 08:14:39 +0200
Message-Id: <9508020614.AA22842@dxcoms.cern.ch>
Subject: (IPng 464) Re: Ethertype and multicast filtering info
To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Date: Wed, 2 Aug 1995 08:14:38 +0200 (MET DST)
From: "Brian Carpenter   CERN-CN" <brian@dxcoms.cern.ch>
In-Reply-To: <9508011704.AA25137@angelo.amd.com> from "Dave Roberts" at Aug 1, 95 10:04:41 am
X-Mailer: ELM [version 2.4 PL23 DXCOMS1]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Dave,
> 
> Sorry, Brian, I didn't mean to finger point.

Nothing to be sorry for.
...
> >  2. Older PCs have trouble with both broadcast and multicast
> >     so reverting to the broadcast ARP model doesn't help.
> 
> I'm not sure what you mean.  Broadcast is just fine for neighbor
> discovery as long as you don't also put your multimedia streams on it.

I disagree. Broadcast storms caused by ARP are real. Even if you don't
worry about this, a broadcast is sure to wake up every host, whereas
a multicast will only wake up hosts that either need it, or are
unlucky enough to have a hash collision.

> Multicast *would be* just fine for neighbor discovery if high
> bandwidth streams weren't also going to use it and cause collisions in
> the current hash filtering schemes.

If there are enough multicast streams on your LAN for this to
be a real performance hit, then your host is dead already.
The various multicast streams will (statistically) collide
with each other in the hash more than with the discovery multicast
group.

I buy this as one more argument for small subnets and
effective multicast pruning, but I don't buy it as an argument
against multicast for discovery.

  Brian
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 03:45:01 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00686; Wed, 2 Aug 95 03:45:01 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00680; Wed, 2 Aug 95 03:44:51 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA02024; Wed, 2 Aug 1995 03:34:10 -0700
Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM)
	id DAA22039; Wed, 2 Aug 1995 03:34:03 -0700
Received: from [138.96.8.81] by pax.inria.fr (8.6.12/8.6.12) with SMTP id MAA08543 for <ipng@sunroof.Eng.Sun.COM>; Wed, 2 Aug 1995 12:33:50 +0200
Date: Wed, 2 Aug 1995 12:33:50 +0200
Message-Id: <199508021033.MAA08543@pax.inria.fr>
X-Authentication-Warning: pax.inria.fr: Host sophmaccdc1.inria.fr claimed to be [138.96.8.81]
X-Sender: huitema@pax.inria.fr
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora F1.4.2
To: ipng@sunroof.Eng.Sun.COM
From: christian.huitema@sophia.inria.fr (Christian Huitema)
Subject: (IPng 465) (IPng) Notation for prefixes?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

The "IPv6 addressing architecture" memo specifies the notation for
addresses, e.g.

                FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

                1080:0:0:0:8:800:200C:417A

but it does not specify any shorthand notation for prefixes. Instead, it
goes into the precise but cumbersome listing of a set of bits, e.g:

     Reserved for NSAP Allocation       0000 001
     Reserved for IPX Allocation        0000 010
     Provider-Based Unicast Address     010
     Reserved for Geographic-
     Based Unicast Addresses            100
     Link Local Use Addresses           1111 1110 10
     Site Local Use Addresses           1111 1110 11

It would be beneficial to have a notation derived from the CICR convention,
e.g.:

     Reserved for NSAP Allocation       2::/7
     Reserved for IPX Allocation        4::/7
     Provider-Based Unicast Address     40::/3
     Reserved for Geographic-
     Based Unicast Addresses            80::/3
     Link Local Use Addresses           FE:80::/9
     Site Local Use Addresses           FE:C0::/9

Does the group agree?

Note that we don't need to rewrite the spec. We can issue a 1 page info RFC
"A convention for prefix notations within IPv6".

Christian Huitema



------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 04:08:30 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00706; Wed, 2 Aug 95 04:08:30 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00700; Wed, 2 Aug 95 04:08:22 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03061; Wed, 2 Aug 1995 03:57:40 -0700
Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM)
	id DAA23560; Wed, 2 Aug 1995 03:57:39 -0700
From: bmanning@ISI.EDU
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA02704>; Wed, 2 Aug 1995 03:57:38 -0700
Posted-Date: Wed, 2 Aug 1995 03:55:08 -0700 (PDT)
Message-Id: <199508021055.AA29509@zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
	id <AA29509>; Wed, 2 Aug 1995 03:55:08 -0700
Subject: (IPng 466) Re:  (IPng) Notation for prefixes?
To: christian.huitema@sophia.inria.fr (Christian Huitema)
Date: Wed, 2 Aug 1995 03:55:08 -0700 (PDT)
Cc: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <199508021033.MAA08543@pax.inria.fr> from "Christian Huitema" at Aug 2, 95 12:33:50 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> It would be beneficial to have a notation derived from the CICR convention,
> e.g.:
> 
>      Reserved for NSAP Allocation       2::/7
>      Reserved for IPX Allocation        4::/7
>      Provider-Based Unicast Address     40::/3
>      Reserved for Geographic-
>      Based Unicast Addresses            80::/3
>      Link Local Use Addresses           FE:80::/9
>      Site Local Use Addresses           FE:C0::/9
> 
> Does the group agree?

A dandy idea...  However, isn't there a bit of ambiguity here?
Please discriminate (for the pathological case of course :) on these prefixs:

	0::/4
	F::/4

My offhand rememberance of the spec is that there are additional, fixed
fields in parts of the address.  IF this is correct, then CIDR notation
and its attendent mindsets on delegation policy, will break.

--bill
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 04:26:24 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00722; Wed, 2 Aug 95 04:26:24 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00716; Wed, 2 Aug 95 04:26:15 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03776; Wed, 2 Aug 1995 04:15:33 -0700
Received: from rodan.UU.NET by mercury.Sun.COM (Sun.COM)
	id EAA25305; Wed, 2 Aug 1995 04:15:33 -0700
Received: by rodan.UU.NET 
	id QQzbar06861; Wed, 2 Aug 1995 07:15:29 -0400
Message-Id: <QQzbar06861.199508021115@rodan.UU.NET>
To: bmanning@ISI.EDU
Cc: christian.huitema@sophia.inria.fr (Christian Huitema),
        ipng@sunroof.Eng.Sun.COM
Subject: (IPng 467) Re: (IPng) Notation for prefixes? 
In-Reply-To: Your message of "Wed, 02 Aug 1995 03:55:08 PDT."
             <199508021055.AA29509@zed.isi.edu> 
Date: Wed, 02 Aug 1995 07:15:29 -0400
From: "Mike O'Dell" <mo@uunet.uu.net>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


then how about F:://24 for "prefix length in last 32-bits"
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 04:29:52 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00734; Wed, 2 Aug 95 04:29:52 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00728; Wed, 2 Aug 95 04:29:44 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03864; Wed, 2 Aug 1995 04:19:03 -0700
Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM)
	id EAA25637; Wed, 2 Aug 1995 04:19:02 -0700
From: bmanning@ISI.EDU
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03066>; Wed, 2 Aug 1995 04:19:00 -0700
Posted-Date: Wed, 2 Aug 1995 04:16:34 -0700 (PDT)
Message-Id: <199508021116.AA29553@zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
	id <AA29553>; Wed, 2 Aug 1995 04:16:34 -0700
Subject: (IPng 468) Re: (IPng) Notation for prefixes?
To: mo@uunet.uu.net (Mike O'Dell)
Date: Wed, 2 Aug 1995 04:16:34 -0700 (PDT)
Cc: bmanning@ISI.EDU, christian.huitema@sophia.inria.fr,
        ipng@sunroof.Eng.Sun.COM
In-Reply-To: <QQzbar06861.199508021115@rodan.UU.NET> from "Mike O'Dell" at Aug 2, 95 07:15:29 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> 
> 
> then how about F:://24 for "prefix length in last 32-bits"
> 

So thats where the immutable line is drawn.  CIDRize the host
part and leave the provider segment alone?  Or is it CIDRize parts
of the provider part and leave the host part and the top end
of the provider part alone?  Or is it something else?

-- 
--bill
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 04:30:08 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00741; Wed, 2 Aug 95 04:30:08 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00735; Wed, 2 Aug 95 04:29:53 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03870; Wed, 2 Aug 1995 04:19:11 -0700
Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM)
	id EAA25646; Wed, 2 Aug 1995 04:19:09 -0700
Received: from dxcoms.cern.ch by dxmint.cern.ch
	id AA05019; Wed, 2 Aug 1995 13:19:06 +0200
Received: by dxcoms.cern.ch
	id AA12791; Wed, 2 Aug 1995 13:19:04 +0200
Message-Id: <9508021119.AA12791@dxcoms.cern.ch>
Subject: (IPng 469) Re:  (IPng) Notation for prefixes?
To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Date: Wed, 2 Aug 1995 13:19:04 +0200 (MET DST)
From: "Brian Carpenter   CERN-CN" <brian@dxcoms.cern.ch>
In-Reply-To: <199508021033.MAA08543@pax.inria.fr> from "Christian Huitema" at Aug 2, 95 12:33:50 pm
X-Mailer: ELM [version 2.4 PL23 DXCOMS1]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Christian,

> It would be beneficial to have a notation derived from the CICR convention,

Comite International de la Croix Rouge?

> e.g.:
> 
>      Reserved for NSAP Allocation       2::/7
>      Reserved for IPX Allocation        4::/7
>      Provider-Based Unicast Address     40::/3
>      Reserved for Geographic-
>      Based Unicast Addresses            80::/3
>      Link Local Use Addresses           FE:80::/9
>      Site Local Use Addresses           FE:C0::/9
> 

I wonder whether it would be necessary sometime in the
future to distinguish a format prefix from a BGP prefix?
In that case we would need to choose a character other
than /, say \. Then you could write

   40:55::\3/16

to indicate a 3 bit format prefix and a 16 bit BGP prefix.

Gets to look messy though. I am glad to see ::/, as an employee
of the organisation that brought you ://

  Brian
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 04:34:25 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00766; Wed, 2 Aug 95 04:34:25 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00760; Wed, 2 Aug 95 04:34:17 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA04005; Wed, 2 Aug 1995 04:23:35 -0700
Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM)
	id EAA26104; Wed, 2 Aug 1995 04:23:35 -0700
From: bmanning@ISI.EDU
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA03135>; Wed, 2 Aug 1995 04:23:33 -0700
Posted-Date: Wed, 2 Aug 1995 04:21:07 -0700 (PDT)
Message-Id: <199508021121.AA29565@zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
	id <AA29565>; Wed, 2 Aug 1995 04:21:08 -0700
Subject: (IPng 470) Re: (IPng) Notation for prefixes?
To: mo@uunet.uu.net (Mike O'Dell)
Date: Wed, 2 Aug 1995 04:21:07 -0700 (PDT)
Cc: bmanning@ISI.EDU, christian.huitema@sophia.inria.fr,
        ipng@sunroof.Eng.Sun.COM
In-Reply-To: <QQzbar06861.199508021115@rodan.UU.NET> from "Mike O'Dell" at Aug 2, 95 07:15:29 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> 
> 
> then how about F:://24 for "prefix length in last 32-bits"
> 

Oh yeah... How well does IPX or NSAP formats deal w/ the concept of
CIDR?

Perhaps the only place that CIDR is applicable is in the

	40::/3 range 

of the IPv6 space.  Other areas a parallel universes with different
methods for address manipulation.


--bill
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 05:35:16 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00812; Wed, 2 Aug 95 05:35:16 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00806; Wed, 2 Aug 95 05:35:08 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06634; Wed, 2 Aug 1995 05:24:25 -0700
Received: from dxmint.cern.ch by mercury.Sun.COM (Sun.COM)
	id FAA01220; Wed, 2 Aug 1995 05:24:20 -0700
Received: from dxcoms.cern.ch by dxmint.cern.ch
	id AA02827; Wed, 2 Aug 1995 14:24:11 +0200
Received: by dxcoms.cern.ch
	id AA16604; Wed, 2 Aug 1995 14:24:08 +0200
Message-Id: <9508021224.AA16604@dxcoms.cern.ch>
Subject: (IPng 471) Re: (IPng) Notation for prefixes?
To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Date: Wed, 2 Aug 1995 14:24:08 +0200 (MET DST)
From: "Brian Carpenter   CERN-CN" <brian@dxcoms.cern.ch>
Reply-To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
In-Reply-To: <199508021121.AA29565@zed.isi.edu> from "bmanning@ISI.EDU" at Aug 2, 95 04:21:07 am
X-Mailer: ELM [version 2.4 PL23 DXCOMS1]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Oh yeah... How well does IPX or NSAP formats deal w/ the concept of
> CIDR?

the NSAP formats would CIDRize amongst themselves, but
cannot CIDRize with the rest except somewhere around the /0 level.

   Brian
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 05:41:38 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00824; Wed, 2 Aug 95 05:41:38 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00818; Wed, 2 Aug 95 05:41:29 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06976; Wed, 2 Aug 1995 05:30:47 -0700
Received: from pax.inria.fr by venus.Sun.COM (Sun.COM)
	id FAA08733; Wed, 2 Aug 1995 05:30:44 -0700
Received: from [138.96.8.81] by pax.inria.fr (8.6.12/8.6.12) with SMTP id OAA09626 for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 1995 14:29:19 +0200
Date: Wed, 2 Aug 1995 14:29:19 +0200
Message-Id: <199508021229.OAA09626@pax.inria.fr>
X-Authentication-Warning: pax.inria.fr: Host sophmaccdc1.inria.fr claimed to be [138.96.8.81]
X-Sender: huitema@pax.inria.fr
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora F1.4.2
To: ipng@sunroof.Eng.Sun.COM
From: christian.huitema@sophia.inria.fr (Christian Huitema)
Subject: (IPng 472) Re:  (IPng) Notation for prefixes?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

>> It would be beneficial to have a notation derived from the CICR convention,
>> e.g.:
>>
Actually, I realize there were mistakes in my initial writing. I meant CIDR
not CICR, and the prefix notation should include the full value:

>>      Reserved for NSAP Allocation       2::/7
should be                                  200::/7
>>      Reserved for IPX Allocation        4::/7
should be                                  400::/7

>>      Provider-Based Unicast Address     40::/3
should be                                  4000::/3
>>      Reserved for Geographic-
>>      Based Unicast Addresses            80::/3
should be                                  8000::/3
>>      Link Local Use Addresses           FE:80::/9
should be                                  FE80::/10
>>      Site Local Use Addresses           FE:C0::/9
should be                                  FEC0::/10

Well, I was not expecting such a distinguished audience to buy even the
simplest of ideas off hand, but lets summarize the objections:

1) There are pathological cases, e.g. how do we distinguish 0::/4 vs F::/4.
(Bill Manning)

Well, yes indeed there are possible mistakes. The same way we distinguish
128/4 and 129/4 today. If people make mistakes, they have to live with
their mistakes.

2) We should distinguish "format prefix" and "BGP prefix", e.g. as in
40:55::\3/16. (Brian Carpenter)

Uh? What happened to "keep it simple", that fundamental principle of the
architecture? The routing protocols, be it IDRP4v6, OSPF4v6, RIP4v6, cannot
be expected to have a hardwired knowledge of all the possible allocation
strategies. If we want to specify that "this is a provider address, and
there are 16 significant bits after the 3 bits prefix", we can as well
write 4055:8000::/19.

3) What about IPX and NSAP addresses? (Bill Manning)

Last time I checked, NSAP addresses had a strict hierarchy of AFI, IDI,
domain(s), area, host and protocol. I expect this hierarchy to translate
easily in a set of variable length prefixes, each of which can be
represented by <v6 address>/<number of bits>. The IPX addresses I know have
a two level hierarchy, net + host. I would expect that the "number of bits"
in this case will encompass the IPX prefix and the IPX network number.

4) What of those fixed fields all around the place?

There are currently a number of reserved fields in some format, e.g. in a
registry/provider/subscriber hierarchy. The notation is neutral. The idea
is:

* to write down a valid IPv6 address,

* to determine the number of bits which describe a specific level in the
routing hierarchy (the one we want to describe).

* to zero all the trailing bits (after the prefix)

* to describe the prefix by writing this (zero terminated) address
according to the standard "address notation" rules, then append a "/" as a
separator and the number of significant bits (decimal).

5) Should we not have a special case for v4 derived addresses, e.g. ::39.13//16

Yes, it makes exactly as much sense as having a special notation for v4
derived addresses.

I will collect the suggestions before sending a fully fledged draft.

Christian Huitema


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 06:57:32 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00846; Wed, 2 Aug 95 06:57:32 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00840; Wed, 2 Aug 95 06:57:23 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11580; Wed, 2 Aug 1995 06:46:40 -0700
Received: from ns.crynwr.com by mercury.Sun.COM (Sun.COM)
	id GAA12088; Wed, 2 Aug 1995 06:46:35 -0700
Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4)
	id m0sde7G-000H96C; Wed, 2 Aug 95 09:45 EDT
Message-Id: <m0sde7G-000H96C@ns.crynwr.com>
Date: Wed, 2 Aug 95 09:45 EDT
From: nelson@crynwr.com (Russell Nelson)
To: brian@dxcoms.cern.ch
Cc: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508020559.AA22438@dxcoms.cern.ch> (brian@dxcoms.cern.ch)
Subject: (IPng 473) Re: Ethertype and multicast filtering info
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   Date: Wed, 2 Aug 1995 07:59:32 +0200 (MET DST)
   From: "Brian Carpenter   CERN-CN" <brian@dxcoms.cern.ch>

   Russ,

   > But I don't agree that it will necessarily cause your hardware to fall
   > over.  DOOM 1.1 broadcasts went out at 100 packets/second.  Nobody
   > noticed until some WAN links got overloaded.

   Are you kidding??

No.

   Any system that fires up doom, xpilot or any similar
   <expletive deleted> around here gets cut off real quick. People
   don't notice because they don't monitor, but 100pps broadcast
   is a performance hit on every other host. This is just as
   true in a dentist's office as on a big network.

I realize that it's a performance hit.  And the costs are real,
particularly when you add them up across all hosts.  But if you're
going to use multicast, they're unavoidable on today's hardware and
software.  Hey, at least on packet drivers you have enough information
to filter them out at the driver level.  Other drivers need to upcall
them regardless.

And if you're upset about the 64-bit hash bucket on the AMD LANCE and
National NIC, wait until you find out about the one bit flag on the
3c5x9 architecture.  You can either get all multicasts, or none.

   Re-read section 5.12 of RFC 1726. I thought we had buried
   this discussion last year.

I realize THAT also.  ARP shouldn't be broadcasting.  Never should
have.  Multicast is your friend.  And we shouldn't let the spectre of
IPng colliding into the same hash bucket as a multimedia stream scare
us into not using it.

kkkI think that the IANA should coordinate the use of the 64 different
hash buckets through careful assignment of multicast addresses.  It
would be a mistake to allow two fixed assignments, one high-use
low-volume and the other low-use high-volume, to fall into the same
hash bucket.  That's Dave Robert's point also.

-- 
-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | Describe the God you don't
Potsdam, NY 13676 | believe in, and I won't believe in that God either.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 07:26:34 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00862; Wed, 2 Aug 95 07:26:34 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00856; Wed, 2 Aug 95 07:26:26 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13832; Wed, 2 Aug 1995 07:15:43 -0700
Received: from pax.inria.fr by mercury.Sun.COM (Sun.COM)
	id HAA16669; Wed, 2 Aug 1995 07:15:37 -0700
Received: from [138.96.8.81] by pax.inria.fr (8.6.12/8.6.12) with SMTP id QAA10877; Wed, 2 Aug 1995 16:15:08 +0200
Date: Wed, 2 Aug 1995 16:15:08 +0200
Message-Id: <199508021415.QAA10877@pax.inria.fr>
X-Authentication-Warning: pax.inria.fr: Host sophmaccdc1.inria.fr claimed to be [138.96.8.81]
X-Sender: huitema@pax.inria.fr
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Eudora F1.4.2
To: nelson@crynwr.com (Russell Nelson), brian@dxcoms.cern.ch
From: christian.huitema@sophia.inria.fr (Christian Huitema)
Subject: (IPng 474) Re: Ethertype and multicast filtering info
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

A (At)  9:45 AM 2/8/95 -0400, Russell Nelson ecrivait (wrote):

>kkkI think that the IANA should coordinate the use of the 64 different
>hash buckets through careful assignment of multicast addresses.  It
>would be a mistake to allow two fixed assignments, one high-use
>low-volume and the other low-use high-volume, to fall into the same
>hash bucket.  That's Dave Robert's point also.

The IANA only allocates some addresses, e.g. "all OSPF routers". The other
addresses are very much allocated at random. This is what SD does on the
MBONE, e.g. for videoconferences.

Your suggestion to partition the address space is interesting. Basically,
it means that we reserve 6 bits somewhere in the multicast address format,
and use them to constraint the low order bits of the CRC-32 to fall into
some category, e.g.

  * 0..15 for IANA assigned addresses,

  * 16..31 for ARP addresses

  * 32..63 for "random" addresses.

Actually, that could work. How much of a solution would this be? 60%? 80%? 90%?

Christian Huitema


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 08:24:50 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00951; Wed, 2 Aug 95 08:24:50 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00945; Wed, 2 Aug 95 08:24:41 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19277; Wed, 2 Aug 1995 08:13:57 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id IAA27153; Wed, 2 Aug 1995 08:13:54 -0700
Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA28869; Wed, 2 Aug 1995 08:04:07 -0700
Received:  from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
	id AA11603; Wed, 2 Aug 1995 11:04:04 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id LAA03620 for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 1995 11:14:57 GMT
Message-Id: <199508021114.LAA03620@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 475) Re: Ethertype and multicast filtering info 
In-Reply-To: Your message of "Wed, 02 Aug 1995 16:15:08 +0200."
             <199508021415.QAA10877@pax.inria.fr> 
X-Mailer: exmh version 1.5omega 10/6/94
Date: Wed, 02 Aug 1995 11:14:55 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


In <199508021415.QAA10877@pax.inria.fr>, Christian Huitema wrote:

> A (At)  9:45 AM 2/8/95 -0400, Russell Nelson ecrivait (wrote):
> 
> >kkkI think that the IANA should coordinate the use of the 64 different
> >hash buckets through careful assignment of multicast addresses.  It
> >would be a mistake to allow two fixed assignments, one high-use
> >low-volume and the other low-use high-volume, to fall into the same
> >hash bucket.  That's Dave Robert's point also.

This would work if there were just one hash algorithm but there isn't.
FWIW, over the years Digital has chosen its multicasts such that they
avoided hash-bucket conflicts for the LANCE, the DEC Ethernet Controllers,
and the Intel 82586.

[...]

> Your suggestion to partition the address space is interesting. Basically,
> it means that we reserve 6 bits somewhere in the multicast address format,
> and use them to constraint the low order bits of the CRC-32 to fall into
> some category, e.g.
> 
>   * 0..15 for IANA assigned addresses,
> 
>   * 16..31 for ARP addresses
> 
>   * 32..63 for "random" addresses.
> 
> Actually, that could work. How much of a solution would this be? 60%? 80%? 90%?

Nope, it can't.  You can't control the hardware addresses so no matter
what range you restrict the various multicasts to there will be a chance
of conflicting with someone's hardware address.

Matt Thomas                          Internet:   thomas@lkg.dec.com
U*X Networking                       WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 08:44:16 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00994; Wed, 2 Aug 95 08:44:16 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA00988; Wed, 2 Aug 95 08:44:08 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21243; Wed, 2 Aug 1995 08:33:24 -0700
Received: from gossip.pyramid.com by mercury.Sun.COM (Sun.COM)
	id IAA01212; Wed, 2 Aug 1995 08:33:16 -0700
Received: from shadow.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA07610; Wed, 2 Aug 95 08:16:11 -0700
Received: by shadow.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06216; Wed, 2 Aug 95 08:15:06 -0700
Date: Wed, 2 Aug 95 08:15:06 -0700
From: moliver@pyramid.com (Mike Oliver)
Message-Id: <9508021515.AA06216@shadow.eng.pyramid.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 476) Re: Ethertype and multicast filtering info
Cc: nelson@crynwr.com
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Russ Nelson <nelson@crynwr.com> wrote:
> And if you're upset about the 64-bit hash bucket on the AMD LANCE and
> National NIC, wait until you find out about the one bit flag on the
> 3c5x9 architecture.  You can either get all multicasts, or none.

Things are even uglier in the Token Ring world.  The widely-used TI
TMS380 chipset lets you configure exactly one multicast address whose
MSB is coerced to 0x03 (== 0xC0 in IEEE bit order).

> I think that the IANA should coordinate the use of the 64 different
> hash buckets ...

Someone has already mentioned that DEC's Ethernet chips use a different
scheme; if I recall correctly they have 512 buckets indexed by the top
9 accumulated CRC bits.  How many implementations should IANA take into
account ?

>          ... through careful assignment of multicast addresses.

Maybe IANA can contrive non-colliding multicast addresses for Internet
protocols, but they have no way of mandating the multicast addresses
used by other protocol families.  The best that could happen would be
IANA assigning numbers to avoid hash collisions with today's multicast
traffic, which would depend on their (its ?) being able to compile a
list of today's common multicast destinations -- or at least the
high-volume ones.

> It would be a mistake to allow two fixed assignments, one high-use
> low-volume and the other low-use high-volume, to fall into the same
> hash bucket.  That's Dave Robert's point also.

That would be an unpleasant situation and I agree that it's worth
expending some effort to avoid clashes with known multicast channels.
But short of negotiating multicast addresses on the fly I don't think
collision-free multicast operation can be guaranteed.

Regards, Mike.
--
moliver@pyramid.com
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 09:18:39 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01019; Wed, 2 Aug 95 09:18:39 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01013; Wed, 2 Aug 95 09:18:31 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA25410; Wed, 2 Aug 1995 09:07:47 -0700
Received: from ns.crynwr.com by mercury.Sun.COM (Sun.COM)
	id JAA08912; Wed, 2 Aug 1995 09:07:35 -0700
Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4)
	id m0sdgJq-000H99C; Wed, 2 Aug 95 12:06 EDT
Message-Id: <m0sdgJq-000H99C@ns.crynwr.com>
Date: Wed, 2 Aug 95 12:06 EDT
From: nelson@crynwr.com (Russell Nelson)
To: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <199508021114.LAA03620@whydos.lkg.dec.com> (message from Matt Thomas on Wed, 02 Aug 1995 11:14:55 +0000)
Subject: (IPng 477) Re: Ethertype and multicast filtering info
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   Date: Wed, 02 Aug 1995 11:14:55 +0000
   From: Matt Thomas <matt@lkg.dec.com>

   In <199508021415.QAA10877@pax.inria.fr>, Christian Huitema wrote:

   > A (At)  9:45 AM 2/8/95 -0400, Russell Nelson ecrivait (wrote):
   > 
   > >kkkI think that the IANA should coordinate the use of the 64 different
   > >hash buckets through careful assignment of multicast addresses.  It
   > >would be a mistake to allow two fixed assignments, one high-use
   > >low-volume and the other low-use high-volume, to fall into the same
   > >hash bucket.  That's Dave Robert's point also.

   This would work if there were just one hash algorithm but there isn't.
   FWIW, over the years Digital has chosen its multicasts such that they
   avoided hash-bucket conflicts for the LANCE, the DEC Ethernet Controllers,
   and the Intel 82586.

Right.  There are too many manufacturers to try to make them all work.
However, if we use the same algorithm as used by the LANCE and the
NIC, that will cover at least 50%, and probably more like 70% of the
adapters out there.

   Nope, it can't.  You can't control the hardware addresses so no matter
   what range you restrict the various multicasts to there will be a chance
   of conflicting with someone's hardware address.

Hmmm...  I thought a deterministic algorithm was used to convert from
the multicast IP addresses into the multicast Ethernet addresses?
Didn't the IANA get its own Ethernet block for exactly that purpose?

I don't think anyone thinks a perfect solution is available.  We don't
need perfection -- we just need to make sure we don't *cause* pain by
an ignorant choice of addresses.

-- 
-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | Describe the God you don't
Potsdam, NY 13676 | believe in, and I won't believe in that God either.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 09:23:50 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01031; Wed, 2 Aug 95 09:23:50 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01025; Wed, 2 Aug 95 09:23:42 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA26143; Wed, 2 Aug 1995 09:12:58 -0700
Received: from ns.crynwr.com by mercury.Sun.COM (Sun.COM)
	id JAA10026; Wed, 2 Aug 1995 09:12:55 -0700
Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4)
	id m0sdgP3-000H99C; Wed, 2 Aug 95 12:12 EDT
Message-Id: <m0sdgP3-000H99C@ns.crynwr.com>
Date: Wed, 2 Aug 95 12:12 EDT
From: nelson@crynwr.com (Russell Nelson)
To: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508021515.AA06216@shadow.eng.pyramid.com> (moliver@pyramid.com)
Subject: (IPng 478) Re: Ethertype and multicast filtering info
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   Date: Wed, 2 Aug 95 08:15:06 -0700
   From: moliver@pyramid.com (Mike Oliver)

   Russ Nelson <nelson@crynwr.com> wrote:

   > It would be a mistake to allow two fixed assignments, one high-use
   > low-volume and the other low-use high-volume, to fall into the same
   > hash bucket.  That's Dave Robert's point also.

   That would be an unpleasant situation and I agree that it's worth
   expending some effort to avoid clashes with known multicast channels.
   But short of negotiating multicast addresses on the fly I don't think
   collision-free multicast operation can be guaranteed.

The best solution would be to choose multicast addresses *at random*.
That would give you a 63 out of 64 chance (>98%) of avoiding conflicts.

The worst solution would be to standardize on a fixed IP address for
multicast routing (or whatever) updates that mapped into a multicast
Ethernet address that fell into the same hash bucket (on many hosts)
as some fixed multicast protocol with very high traffic
(e.g. multimedia).  The combination of two fixed addresses would be
broken!

-- 
-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | Describe the God you don't
Potsdam, NY 13676 | believe in, and I won't believe in that God either.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 09:39:34 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01061; Wed, 2 Aug 95 09:39:34 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01055; Wed, 2 Aug 95 09:39:25 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28346; Wed, 2 Aug 1995 09:28:41 -0700
Received: from BBN.COM by mercury.Sun.COM (Sun.COM)
	id JAA14405; Wed, 2 Aug 1995 09:28:30 -0700
Received: from aland.bbn.com by BBN.COM id aa28556; 2 Aug 95 12:15 EDT
Received: by aland.bbn.com (8.6.12/3.1.090690-BBN)
	id JAA15864; Wed, 2 Aug 1995 09:05:35 -0700
Message-Id: <199508021605.JAA15864@aland.bbn.com>
To: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Subject: (IPng 479) Multicast vs. broadcast
Reply-To: Craig Partridge <craig@aland.bbn.com>
From: Craig Partridge <craig@aland.bbn.com>
Date: Wed, 02 Aug 95 09:05:35 -0700
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Hi folks:

Some of the recent notes have me tremendously confused, as there seem to
be folks arguing that using broadcast in IPv6 is better than multicast and
I cannot puzzle out what is the motivation behind this idea.

Even if some network adapters have poor granularity of multicast hash
functions it seems to me that multicast is always better than broadcast
for the following reason:

    Broadcast hits every host on the network, while multicast hits only those
    hosts who either (a) wanted to hear the multicast or (b) had the
    misfortune to be listening to another multicast group with the same
    hash value.

In a multiprotocol environment, this is clearly a win, since hosts that
aren't running IPv6 don't get harmed by IPv6 multicast (except in the case
of group overlap -- which may be a nuisance, but is still much better than
broadcast, where you are effectively overlapping all the time).

Can someone explain to me why we are even considering broadcasts?

Confused...

Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 10:04:40 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01112; Wed, 2 Aug 95 10:04:40 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01106; Wed, 2 Aug 95 10:04:32 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA02387; Wed, 2 Aug 1995 09:53:48 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id JAA20415; Wed, 2 Aug 1995 09:53:39 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA09437; Wed, 2 Aug 1995 09:53:32 -0700
Received: by xirtlu.zk3.dec.com; id AA17642; Wed, 2 Aug 1995 12:53:28 -0400
Message-Id: <9508021653.AA17642@xirtlu.zk3.dec.com>
To: Craig Partridge <craig@aland.bbn.com>
Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Subject: (IPng 480) Re:  Multicast vs. broadcast 
In-Reply-To: Your message of "Wed, 02 Aug 95 09:05:35 PDT."
             <199508021605.JAA15864@aland.bbn.com> 
Date: Wed, 02 Aug 95 12:53:22 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Craig,

I only recall one message that talked about using broadcast.  Most have
been about how efficient the hash is for multicast,  So I am confused by
your confusion.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 11:30:03 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01269; Wed, 2 Aug 95 11:30:03 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01263; Wed, 2 Aug 95 11:29:50 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16791; Wed, 2 Aug 1995 11:18:43 -0700
Received: from ncc.ripe.net by mercury.Sun.COM (Sun.COM)
	id LAA14946; Wed, 2 Aug 1995 11:18:36 -0700
Received: from belegen.ripe.net by ncc.ripe.net with SMTP
	id AA08751 (5.65a/NCC-2.26); Wed, 2 Aug 1995 20:17:34 +0200
Message-Id: <9508021817.AA08751@ncc.ripe.net>
To: Craig Partridge <craig@aland.bbn.com>
Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List)
From: Geert Jan de Groot <GeertJan.deGroot@ripe.net>
X-Organization: RIPE Network Coordination Centre
X-Phone: +31 20 592 5065
Subject: (IPng 481) Re:  Multicast vs. broadcast 
In-Reply-To: Your message of "Wed, 02 Aug 1995 09:05:35 PDT."
             <199508021605.JAA15864@aland.bbn.com> 
Date: Wed, 02 Aug 1995 20:17:23 +0200
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Hi,

On Wed, 02 Aug 95 09:05:35 -0700  Craig Partridge wrote:
> Some of the recent notes have me tremendously confused, as there seem to
> be folks arguing that using broadcast in IPv6 is better than multicast and
> I cannot puzzle out what is the motivation behind this idea.

Since I was one of the persons that brought this up originally,
I'd better speak up. Sorry for not responding earlier, but
we have been overcommitted at the NCC lately and the weather isn't
helping (it's HOT here).

One of the features of ethernet is that the receiver does
packet filtering in hardware. Adapters filter on the destination
MAC-address. If the address does not match, then the receiver
does not receive the packet and the host CPU never knows what
it missed.

There are 3 possibilities:
- Unicast: the packet is only received if the destination MAC-address
  matches the MAC-address that the controller has been programmed to
  (the 'ethernet address');
- Multicast: Ideally, multicast packets are only received if there
  is a multicast application that can process these packets;
- Broadcast: all adapters pass these on to their hosts.

An advantage of this scheme is that while an ethernet may
utilized for 10MBps, the bandwith between the adapter and the
host may be much lower because the intent is that the majority
of the packets never pass the receiver.
This is important because the bandwith between the receiver
and the host CPU may be limited by hardware constraints
(SCSI ethernet adapters, 'printerport' ethernet adapters,
ISA-bus ethernet adapters (?)), or by software.
For 'software' I aim at all the code that is used before it
is decided that a packet should be discarded. All this code
will run for every packet, so I include the time spent in
this driver code in my 'bandwith' definition above.

If an adapter would not filter, then a host has to process
every packet, and needs to decide if it should be processed
or discarded. It is easy to understand why this hardware
filtering is done. 

Looking at ethernet adapters today, one finds several approaches:
1. Adapters that have a limited set of multicast slots that
   a destination MAC address is compared against. 
   (if one runs out of slots, then the controller is switched
   to promicious mode and filtering done in software)
   To the best of my knowledge, these adapters are rare.
2. Adapters that use some kind of hashing mechanism to
   find an index in a table (64 slots in most cases, 8390, lance).
   If this table entry is 1, the packet is passed, if it is 0,
   the packet is discarded by the receiver.
3. Adapters that can only enable either none or all multicast
   traffic. There are even modern examples of this approach;
   this is not a sign of an 'outdated design' or something
   like that.

The problem is with category 2 and 3. 
Imagine what would happen if a high-bandwith multicast app
would use an ethernet multicast address that, after hashing,
clashes with an addres used by Neighbour Discovery.
In that case, the host CPU must process the packet to decide
to discard it. Worse, in order to do that, the packet may have
to be transmitted over a 'bus' that cannot take the bandwith
of the high-bandwith multicast app, as described above.
The ethernet interface would be rendered essentially unusable
because of the congestion between the adapter and the host CPU.
(it may also be that the host CPU spends all its time processing
these packets, rendering the host CPU unusable).

In case 3, there is no workaround apart from not using multicast
at all. In case 2, a workaround is very difficult because different
hashing mechanisms are used (as discussed earlier) so clashes
are difficult to predict.

For IPv4, this is not a problem because the vast majority of 
IPv4 functionality only uses unicast and broadcast (for ARP,
and maybe for a router discovery protocol like RIP).
The limitations of using broadcasts are well understood and
from the beginning, large efforts have been made to minimize
multicast traffic (ignoring DOOM for a moment ;-)
A host could happily interoperate on IPv4 using only unicast and
broadcast functionality.

For IPv6, this unfortunately no longer is the case. Multicasting
is *required* for IPv6 functionality, because of Neighbour
Discovery and similar protocols. An IPv6 host cannot interoperate
without ND functionality, hence cannot interoperate without mulcast.
Sooner or later, and difficult to predict, some ipv6 hosts may
stop operating because a high-bandwith app is started on the
network, which causes the congestion problems above.

I don't think it is fair to say that this 'outdated' hardware
should be replaced. First, because it is the majority of the
market (have you seen some $25 NE2000 clone cards recently?
they all have to be replaced!); second, because the same flaw
is in high-end machines (though, because the adapter-host
bandwith usually is better, this is much less of a problem);
third, because a hardware solution currently does not seem
to be wide-spread, if available at all.
There will always be 'slow' busses as network technology
moves on

For this reason, I suggested to go through the list of
IPv6 multicast protocols to select the ones that:
- are *essential* to ipv6 operation
- have low bandwith requirements
and at least keep the possibility open that these protocols
use broadcast instead (for instance, config switch).

If we don't, we should realize that future 'hacks' like 
today's SCSI-ethernet adapters, or printerport adapters,
may well be impossible unless:
- The adapter-CPU bandwith (hardware and software) is 
  always faster than the media;
- Drastically changed ethernet-controllers will be availble
  cheap, and have replaced nearly all current designs.
- We accept random, and hard to explain failures and
  interactions

I have not looked at making drivers for those new switchable 
10/100 Mb ethernet adapters yet, but I can hardly imagine 
current generic hardware/software that is able to process 
a 100 MB ethernet running essentially in promiscuous mode...


Geert Jan

Quote:
   "Imagine that Cray computer decides to make a personal computer.  It has
   a 150 MHz processor, 200 megabytes of RAM, 1500 megabytes of disk
   storage, a screen resolution of 1024 x 1024 pixels, relies entirely on
   voice recognition for input, fits in your shirt pocket and costs $300.
   What's the first question that the computer community asks?
   
   "Is it PC compatible?"

- Early BSD 4.3 (4.2?) fortune


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 11:59:12 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01293; Wed, 2 Aug 95 11:59:12 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01287; Wed, 2 Aug 95 11:59:03 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA22399; Wed, 2 Aug 1995 11:48:17 -0700
Received: from BBN.COM by mercury.Sun.COM (Sun.COM)
	id LAA22424; Wed, 2 Aug 1995 11:48:07 -0700
Received: from aland.bbn.com by BBN.COM id aa14244; 2 Aug 95 14:37 EDT
Received: by aland.bbn.com (8.6.12/3.1.090690-BBN)
	id LAA16190; Wed, 2 Aug 1995 11:38:32 -0700
Message-Id: <199508021838.LAA16190@aland.bbn.com>
To: Geert Jan de Groot <GeertJan.deGroot@ripe.net>
Cc: ipng@sunroof.Eng.Sun.COM (IPv6 List)
Subject: (IPng 482) Re:  Multicast vs. broadcast 
In-Reply-To: Your message of Wed, 02 Aug 95 20:17:23 +0200.
             <9508021817.AA08751@ncc.ripe.net> 
Date: Wed, 02 Aug 95 11:38:31 -0700
From: Craig Partridge <craig@aland.bbn.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Hi:
    
    Thanks for the explanation.  Let me see if I can summarize what
I think is the gist of the issue:

    There is a substantial chance that, due to limitations in
    network adapters, multimedia multicasts will periodically
    share a multicast group with the neighbor discovery multicast
    group.  For some adapters this chance is 100% since they
    accept all or none multicast.

    To remedy this, the proposal is to resume using a known
    bad practice, namely broadcast.  On the theory that we know
    it is a bad practice but at least know the risks, we'll put
    low frequency traffic on the broadcast group.

I find this approach upsetting, since it isn't clear to me that other
alternatives have been considered.  Instead of going back to a bad solution,
let's try to find a good one.  Here a couple right off the top of my
head (and I'm sure there are better ones):

    1. Recommend that hosts that cannot sink high rates of multicast
    traffic be isolated on separate subnets.  If having a multimedia
    multicast clash with the ND group will cause your host to die,
    that host presumably is not suitable for MBONE-type traffic and
    can and should be isolated by a router.  We all know how to subnet
    to protect systems and it doesn't have the same problems as broadcast.
    Note this protects against both hash conflicts and hosts which have
    all-or-nothing multicast -- there won't be enough multicast traffic
    on the subnet to overload the all-or-nothing adapters.

    2. Use multiple multicast groups for ND -- send ND info on say
    two different multicast groups.  Then hosts which suddenly see a
    lot of multicast traffic they don't want can consider jumping to the
    other ND group to try to get a lower hit rate.  This helps against
    hash bucket conflicts -- it doesn't help all-or-nothing adapters.
    And since ND traffic low rate, presumably sending it twice doesn't
    hurt...

Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 12:19:11 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01310; Wed, 2 Aug 95 12:19:11 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01303; Wed, 2 Aug 95 12:19:02 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA25372; Wed, 2 Aug 1995 12:08:20 -0700
Received: from ns.crynwr.com by venus.Sun.COM (Sun.COM)
	id MAA22609; Wed, 2 Aug 1995 12:08:18 -0700
Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4)
	id m0sdivx-000H97C; Wed, 2 Aug 95 14:54 EDT
Message-Id: <m0sdivx-000H97C@ns.crynwr.com>
Date: Wed, 2 Aug 95 14:54 EDT
From: nelson@crynwr.com (Russell Nelson)
To: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <199508021605.JAA15864@aland.bbn.com> (message from Craig Partridge on Wed, 02 Aug 95 09:05:35 -0700)
Subject: (IPng 483) Re:  Multicast vs. broadcast
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   From: Craig Partridge <craig@aland.bbn.com>
   Date: Wed, 02 Aug 95 09:05:35 -0700

   Some of the recent notes have me tremendously confused, as there seem to
   be folks arguing that using broadcast in IPv6 is better than multicast and
   I cannot puzzle out what is the motivation behind this idea.

I don't necessarily agree with this analysis, but here is the idea:

Every broadcast is a waste of host resources because N-1 machines
don't want it (usually).  You can reduce that waste by using
multicast, which only wastes resources on the machines that are
participating in the protocol.  Yet if IPv6 is going to be the
all-singing, all-dancing, stand-up-and-be-saved protocol, people are
going to be using it for everything.  So that most hosts are going to
be running IPv6.  And if that's the case, then a multicast protocol
that's required by IPv6 is going to be received by everyone.  So much
for saving CPU time.

Now we have everyone listening to this multicast port.  But IPv6 is
all-singing, all-dancing, so some people will be using it for
multicast multimedia (translation: high, constant-rate traffic).  Most
Ethernet controllers hash on only six bits of the incoming multicast
address.  If the required multicast port falls into the same bucket as
the multimedia multicasts, YOUCH!

You end up with EVERY host receiving the multimedia stream, with no
way for the hardware to discard it, other than to upgrade to vaporware
hardware.  Now you're not saving CPU time, you're wasting it.  This is
a pathological case that wouldn't happen if IPv6 used broadcasts.

<shrug>.  Don't know if I agree with it, but that's how the case is stated.

-- 
-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | Describe the God you don't
Potsdam, NY 13676 | believe in, and I won't believe in that God either.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 12:47:49 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01382; Wed, 2 Aug 95 12:47:49 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01376; Wed, 2 Aug 95 12:47:35 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29150; Wed, 2 Aug 1995 12:36:22 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id MAA01774; Wed, 2 Aug 1995 12:36:15 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa01098;
          2 Aug 95 20:34 GMT
To: Geert Jan de Groot <GeertJan.deGroot@ripe.net>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 484) Re: Multicast vs. broadcast 
In-Reply-To: Your message of "Wed, 02 Aug 1995 20:17:23 +0200."
             <9508021817.AA08751@ncc.ripe.net> 
Date: Wed, 02 Aug 1995 15:34:46 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508022034.aa01098@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <9508021817.AA08751@ncc.ripe.net>, Geert Jan de Groot writes:
>On Wed, 02 Aug 95 09:05:35 -0700  Craig Partridge wrote:
>> Some of the recent notes have me tremendously confused, as there seem to
>> be folks arguing that using broadcast in IPv6 is better than multicast and
>> I cannot puzzle out what is the motivation behind this idea.

>I don't think it is fair to say that this 'outdated' hardware
>should be replaced. First, because it is the majority of the
>market (have you seen some $25 NE2000 clone cards recently?
>they all have to be replaced!); second, because the same flaw
>is in high-end machines (though, because the adapter-host
>bandwith usually is better, this is much less of a problem);
>third, because a hardware solution currently does not seem
>to be wide-spread, if available at all.
>There will always be 'slow' busses as network technology
>moves on

	There are two problems I have with this argument.

	The first one is the old "You get what you pay for". If you buy
a $25 NE2000 board, you're not buying it because you want high performance,
you're buying it because you want *cheap*. So you're saying we should
design the next generation of the Internet protocols not to facilitate
high-performance multicast-capable hardware but to maximize performance on
hardware that is already the result of a consumer choice to save a few
bucks at the expense of performance?

	The second is that multicast is so poorly supported right now
because so few applications use it. If we build a protocol suite that
requires the use of multicast and the mass market accepts it, manufacturers
will improve their multicast support. If we build a protocol suite that
doesn't use multicast very much, then manufacturers won't have much
incentive to improve their multicast support. We need to drive multicast
technology here.

								-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 13:07:19 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01418; Wed, 2 Aug 95 13:07:19 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01361; Wed, 2 Aug 95 12:41:24 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28206; Wed, 2 Aug 1995 12:28:54 -0700
Received: from muenster.westfalen.de by mercury.Sun.COM (Sun.COM)
	id MAA00320; Wed, 2 Aug 1995 12:27:53 -0700
Received: by muenster.westfalen.de (/\oo/\ Smail3.1.29.0 #29.4)
	id <m0sdjRe-0005CMC@muenster.westfalen.de>; Wed, 2 Aug 95 21:27 MET DST
Received: by khms.westfalen.de (CrossPoint v3.02 R/C435);
	  02 Aug 1995 21:13:10 +0200
Date: 02 Aug 1995 18:20:00 +0200
From: kai@khms.westfalen.de (Kai Henningsen)
To: ipng@sunroof.Eng.Sun.COM
Message-Id: <5r6TKRQjcsB@khms.westfalen.de>
In-Reply-To: <199508021229.OAA09626@pax.inria.fr>
Subject: (IPng 485) Re: (IPng) Notation for prefixes?
X-Mailer: CrossPoint v3.02 R/C435
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Organization: Organisation? Me?! Are you kidding?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

christian.huitema@sophia.inria.fr wrote on 02.08.95 in <199508021229.OAA09626@pax.inria.fr>:

> 5) Should we not have a special case for v4 derived addresses, e.g.
> ::39.13//16

With the original algorithm, that would be ::39.13.0.0/112. It's no  
problem to leave the 0.0 out, but I don't think it would be a good idea to  
change the /112 to /16. (And remember it might be ::FFFF:39.13.0.0/112!)

MfG Kai

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 13:09:34 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01447; Wed, 2 Aug 95 13:09:34 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01402; Wed, 2 Aug 95 13:01:36 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA01152; Wed, 2 Aug 1995 12:50:51 -0700
Received: from panix4.panix.com by mercury.Sun.COM (Sun.COM)
	id MAA04759; Wed, 2 Aug 1995 12:50:33 -0700
Received: from panix2.panix.com (panix2.panix.com [198.7.0.3]) by panix4.panix.com (8.6.12/8.6.12+PanixU1.1) with SMTP id PAA25585; Wed, 2 Aug 1995 15:50:07 -0400
Message-Id: <199508021950.PAA25585@panix4.panix.com>
To: nelson@crynwr.com (Russell Nelson)
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 486) Re: Multicast vs. broadcast 
In-Reply-To: Your message of "Wed, 02 Aug 1995 14:54:00 EDT."
             <m0sdivx-000H97C@ns.crynwr.com> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 02 Aug 1995 15:50:06 -0400
From: "Perry E. Metzger" <perry@panix.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Russell Nelson writes:
> I don't necessarily agree with this analysis, but here is the idea:
[...]
> multicast multimedia (translation: high, constant-rate traffic).  Most
> Ethernet controllers hash on only six bits of the incoming multicast
> address.  If the required multicast port falls into the same bucket as
> the multimedia multicasts, YOUCH!

The IETF credo is experimentation and implementation before standardization.

This seems to be a case where testing the idea out in the field would
quickly tell us if we have an unworkable problem or not -- it would in
fact tell us far quicker than abstract argument in the absense of facts.

Perry

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 13:26:29 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01483; Wed, 2 Aug 95 13:26:29 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01477; Wed, 2 Aug 95 13:26:21 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA04712; Wed, 2 Aug 1995 13:15:32 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id NAA09629; Wed, 2 Aug 1995 13:15:28 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15772(6)>; Wed, 2 Aug 1995 13:15:00 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 2 Aug 1995 13:14:47 -0700
To: David.Roberts@amd.com (Dave Roberts)
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 487) Re: Ethertype and multicast filtering info 
In-Reply-To: nelson's message of Wed, 02 Aug 95 06:45:00 -0800.
             <m0sde7G-000H96C@ns.crynwr.com> 
Date: Wed, 2 Aug 1995 13:14:37 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug2.131447pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

First, thanks very much to Dave Roberts for his report on PC driver support
for new ethertypes and on the state of LAN multicast address filters.  It
sounds like our decision to go with a new ethertype for IPv6 will be OK
with PC-based IP stack vendors.

Now, on this subject of multicast address filters...

> From:	nelson@crynwr.com (Russell Nelson)
>
> I think that the IANA should coordinate the use of the 64 different
> hash buckets through careful assignment of multicast addresses.  It
> would be a mistake to allow two fixed assignments, one high-use
> low-volume and the other low-use high-volume, to fall into the same
> hash bucket.  That's Dave Robert's point also.

When I was designing IP multicast, I thought of this, but gave it up as
hopeless when I learned that, even though both the LANCE chip and the
Intel 82586 chip used the same 6-bits-from-the-CRC-as-hash algorithm,
they each used a *different* 6 bits from the CRC!  Thus, avoiding collisions
for one chip does not assure avoidance of collisions on the other chip.

I was surprised that Digital went so far as what Matt Thomas said:

> FWIW, over the years Digital has chosen its multicasts such that they
> avoided hash-bucket conflicts for the LANCE, the DEC Ethernet Controllers,
> and the Intel 82586.

That works for a relatively limited number of fixed, well-known multicast
addresses (many fewer than 64 addresses) in a single-protocol world (or
at least a world with a single multicast address administrator), but it's
clearly unworkable for large numbers of dynamically allocated multicast
addresses, such as those used by the MBone tools.

So, I decided not to constrain the IP multicast design to the inadequacies
of current hardware, and figured that the hardware would improve over time
as the value of multicast became evident.  I thought the performance
penalty incurred by inadequate filters might act as an incentive for
people to upgrade to more capable interfaces.  I congratulate Digital
on having the forsight to put decent multicast filters on their chips,
and I hope the market rewards them for that.

I also think this notion that PCs will be content just to listen to low-rate
traffic on the broadcast address has a very short shelf life -- those PCs
(or, rather, the owners of those PCs) will very soon, if not already, want
to listen to multicast, multi-media traffic (over IPv4 or other protocols,
not just IPv6), so they are going to be subjected to the hash-collision
hazard anyway.  They'll cope either by burning CPU or by upgrading their
interfaces, just like they keep upgrading their disks and their sound cards
and their video codecs and ...

By the way, a couple of messages in this thread gave the impression that
the probability of hash collisions between randomly-allocated multicast
addresses was relatively small (like 1/64).  This is *false*.  Go and
look up the Birthday Problem in a probability text.  By the time you
reach 10 randomly-chosen multicast address, the probability of a collison
exceeds 50%!

The bits-from-CRC-as-hash algorithm is very clever and elegant, but I've
always been dismayed that the designers used so few buckets.  Instead of
6 bits from the CRC (64 buckets), they should have used at least
16 bits (64*K* buckets) -- all it would take is a 64K x 1 memory, which
ought to fit into the corner of a present-day chip, right?

Anyway, I vote for Craig's solution: those devices that can't stand the
heat ought to be placed on separate cables (retirement homes?), separated
by routers or by smart bridges/hubs/switches that can be configured
to filter out all but a small set of multicast addresses.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 13:38:15 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01495; Wed, 2 Aug 95 13:38:15 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01489; Wed, 2 Aug 95 13:38:06 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06630; Wed, 2 Aug 1995 13:27:23 -0700
Received: from interlan.interlan.com by mercury.Sun.COM (Sun.COM)
	id NAA12473; Wed, 2 Aug 1995 13:27:15 -0700
Received: from rimail.InterLan.COM by interlan.interlan.com with SMTP (5.65/25-eef)
	id AA27931; Wed, 2 Aug 95 16:17:11 -0400
Received: from ccMail by rimail.interlan.com
	id AA807406170 Wed, 02 Aug 95 16:29:30 EST
Date: Wed, 02 Aug 95 16:29:30 EST
From: "CHING, LARRY" <CHINGL@rimail.interlan.com>
Encoding: 1302 Text
Message-Id: <9507028074.AA807406170@rimail.interlan.com>
To: GeertJan.deGroot@ripe.net, Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 488) Re: Multicast vs. broadcast 
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


     

     The second is that multicast is so poorly supported right now because 
     so few applications use it. If we build a protocol suite that requires 
     the use of multicast and the mass market accepts it, manufacturers 
     will improve their multicast support. If we build a protocol suite 
     that doesn't use multicast very much, then manufacturers won't have 
     much incentive to improve their multicast support. We need to drive 
     multicast technology here.
     
Well, OK.  But let's take a look at another example.  Novell file servers 
are often configured to broadcast the services that they provide to all of 
the clients on the net.  When in this configuration, each file server 
broadcasts one packet per service per second.  We have over 20 file servers 
on our net, with many, many print queues.  This generates more than the 100 
pkts/sec mentioned for DOOM!

This overhead remains constant regardless of network speed.  So going to 
100 MBPS Ethernet does not imply more broadcast traffic.  Now, I realize 
that ARP traffic will be generated by every IPV6 node, but traffic rate is 
also moderated by ARP table caching and timeout configuration.  So, just 
how much traffic are we talking about?

Larry Ching
Racal InterLan
     
     
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 14:34:26 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01553; Wed, 2 Aug 95 14:34:26 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01547; Wed, 2 Aug 95 14:34:18 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14422; Wed, 2 Aug 1995 14:23:34 -0700
Received: from interlan.interlan.com by mercury.Sun.COM (Sun.COM)
	id OAA24170; Wed, 2 Aug 1995 14:23:24 -0700
Received: from rimail.InterLan.COM by interlan.interlan.com with SMTP (5.65/25-eef)
	id AA28723; Wed, 2 Aug 95 17:13:07 -0400
Received: from ccMail by rimail.interlan.com
	id AA807409530 Wed, 02 Aug 95 17:25:30 EST
Date: Wed, 02 Aug 95 17:25:30 EST
From: "CHING, LARRY" <CHINGL@rimail.interlan.com>
Encoding: 536 Text
Message-Id: <9507028074.AA807409530@rimail.interlan.com>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 489) Re: Multicast vs. broadcast 
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


     
> Now, I realize that ARP traffic will be generated by every IPV6 node, 
>but traffic rate is also moderated by ARP table caching and timeout 
>configuration.  So, just how much traffic are we talking about?
     
     Ooops.  Getting late in the day.  What I meant was, ARP traffic is, of 
     course, generated by every *IPV4* node, not just the server.  Also, 
     what is the expected comparsion between IPV4 ARP traffic and IPV6 ND 
     traffic in terms of pkts/sec?
     
     Larry Ching
     Racal InterLan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 15:59:08 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01629; Wed, 2 Aug 95 15:59:08 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01623; Wed, 2 Aug 95 15:59:00 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA26559; Wed, 2 Aug 1995 15:48:15 -0700
Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM)
	id PAA12464; Wed, 2 Aug 1995 15:48:13 -0700
Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id PAA04857 for <ipng@sunroof.eng.sun.com>; Wed, 2 Aug 1995 15:47:29 -0700
X-Sender: hinden@mailhost.ipsilon.com
Message-Id: <v02130506ac459411f423@[204.160.241.224]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 2 Aug 1995 15:49:56 -0700
To: ipng@sunroof.Eng.Sun.COM
From: hinden@Ipsilon.COM (Bob Hinden)
Subject: (IPng 490) Updated IPng WWW Pages
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

The IPng WWW pages have been updated.  Changes include information on new
IPng implementations, pointers to current versions of the specifications,
and new instructions to retrieve the mail archives.  The URL is:

        http://playground.sun.com/pub/ipng/html/ipng-main.html

Bob


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 20:15:27 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01855; Wed, 2 Aug 95 20:15:27 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01849; Wed, 2 Aug 95 20:15:18 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA22866; Wed, 2 Aug 1995 20:04:34 -0700
Received: from ns.crynwr.com by mercury.Sun.COM (Sun.COM)
	id UAA21548; Wed, 2 Aug 1995 20:04:34 -0700
Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4)
	id m0sdqZH-000H96C; Wed, 2 Aug 95 23:03 EDT
Message-Id: <m0sdqZH-000H96C@ns.crynwr.com>
Date: Wed, 2 Aug 95 23:03 EDT
From: nelson@crynwr.com (Russell Nelson)
To: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <95Aug2.131447pdt.75270@digit.parc.xerox.com> (message from Steve Deering on Wed, 2 Aug 1995 13:14:37 PDT)
Subject: (IPng 491) Re: Ethertype and multicast filtering info
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   Date: Wed, 2 Aug 1995 13:14:37 PDT
   From: Steve Deering <deering@parc.xerox.com>

   By the way, a couple of messages in this thread gave the impression that
   the probability of hash collisions between randomly-allocated multicast
   addresses was relatively small (like 1/64).  This is *false*.

I should have explicitly said "two" randomly-allocated multicast addresses.
And, the problem is not whether two random addresses collide, but
whether ND and a multimedia address collide.

   The bits-from-CRC-as-hash algorithm is very clever and elegant, but I've
   always been dismayed that the designers used so few buckets.  Instead of
   6 bits from the CRC (64 buckets), they should have used at least
   16 bits (64*K* buckets) -- all it would take is a 64K x 1 memory, which
   ought to fit into the corner of a present-day chip, right?

Nope, not right.  The SMC 91C92 has 4.9Kbytes (or some other really
weird amount) of buffer space.  The 3Com 3c509 has 4Kbytes, the 3c509B
has 6Kbytes.  The Cirrus Logic CS8900 has 4Kbytes.

All the new silicon for mass-market boards either puts everything but
the EEPROM and boot PROM on one chip, or else uses bus-mastering.

   Anyway, I vote for Craig's solution: those devices that can't stand the
   heat ought to be placed on separate cables (retirement homes?), separated
   by routers or by smart bridges/hubs/switches that can be configured
   to filter out all but a small set of multicast addresses.

Yes.  It's my feeling that the multicast hardware isn't any better
because there isn't any market pressure for it.  If IPv6 uses
multicast, that creates the pressure right there.

-- 
-russ <nelson@crynwr.com>    http://www.crynwr.com/~nelson
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | Describe the God you don't
Potsdam, NY 13676 | believe in, and I won't believe in that God either.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 22:26:29 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01905; Wed, 2 Aug 95 22:26:29 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01899; Wed, 2 Aug 95 22:26:21 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28255; Wed, 2 Aug 1995 22:15:35 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id WAA01939; Wed, 2 Aug 1995 22:12:57 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA28597; Wed, 2 Aug 1995 22:08:42 -0700
Received: by xirtlu.zk3.dec.com; id AA28588; Thu, 3 Aug 1995 01:08:39 -0400
Message-Id: <9508030508.AA28588@xirtlu.zk3.dec.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 492) Re: Multicast vs. broadcast 
In-Reply-To: Your message of "Wed, 02 Aug 95 17:25:30 EST."
             <9507028074.AA807409530@rimail.interlan.com> 
Date: Thu, 03 Aug 95 01:08:33 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Ya know folks we have seen this movie and I don't mind seeing it again
but someone really needs to volunteer to put together the FAQ for IPv6
so we can send it out when these kind of discussions begin.

I agree with Perry lets test it out.  Me and my colleagues will have a 
complete ND system implemented before Dallas IETF.  Someone want to
build that killer app to multicast and we will blast it over the link
with other implementations.  But until we can really prove the spec
won't work on multicast (we probably need an IPv6 version of RFC 1112)
lets not change our strategy.

Also I am very concerned we keep heading towards the weakest point in
technology today in some of our decisions like an Internet MTU of 576.
It should be 1500.  If there is only a few vendors who can't support
something do we not do it if its something that can be updated and will
be in the IPv6 market anyway?  Do you think I am happy about dealing
with how to get encryption into an IPv6 implementation then be able to
rebuild it in other countries, but thats not the point, that is what the
IETF has agreed to on consensus, so I will support and attempt to do it.
Most of us know Multicast is better and know it will solve many more
network problems than a bad choice like broadcast.  So lets just do it.
But all means please lets test it too.

/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  2 22:58:35 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01942; Wed, 2 Aug 95 22:58:35 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA01936; Wed, 2 Aug 95 22:58:27 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29470; Wed, 2 Aug 1995 22:47:41 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id WAA04666; Wed, 2 Aug 1995 22:47:43 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA05908; Wed, 2 Aug 1995 22:44:40 -0700
Received: by xirtlu.zk3.dec.com; id AA28982; Thu, 3 Aug 1995 01:44:38 -0400
Message-Id: <9508030544.AA28982@xirtlu.zk3.dec.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 493) YO got an IPv6 Tunnel to test at the TCP/IP EXPO....
Date: Thu, 03 Aug 95 01:44:32 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Wanted to send this here too, just in case someone is not on the
implementors list.

/jim

---------------------
Return-Path: bound
Message-Id: <9508030537.AA28928@xirtlu.zk3.dec.com>
To: ipv6imp@munnari.oz.au
Cc: bound@zk3.dec.com
Subject: YO got an IPv6 Tunnel to test at the TCP/IP EXPO....
Date: Thu, 03 Aug 95 01:37:16 -0400
From: bound
X-Mts: smtp

Hi,

I will have several ipv6 nodes at the TCP/IP EXPO next week.  If you send me
your address I will attempt to tunnel to the node from the show floor.
I will check my mail as late as midnight Saturday if you send me an
address or you can leave me voice mail at (603) 881-0400 as of Sunday 
as I am not clear when we will get the shownet up and connected to the
Internet.  

I have had our sipper v6test node down off the firewall to add ND to the
kernel and will be putting it back up on the Internet this Saturday. Its
node address is 204.123.39.2. pingv6, telnetv6, and ftpv6 can be used.
ftpv6 has anon login, telnetv6 login: guest, passwd: GUEST it will not
let you on just  run netstatv6 -rn, netstatv6 -aA, and netstatv6 -i so you
see the IPv6 environment is happening.  I will be running tcpdump to
catch the tunnel packets to look at later.  You can leave ftp files on
the node thats cool and I will read them occasionally.  Put them in pub
dir and I left you all a hithere.txt file too.

I will be doing an IPv6 Implementation Experience session at EXPO as
this is public I have no problem letting folks have copy of slides after
next week, but you need to send me PRIVATE mail if you want them.

have a good time v6ing its the new way to be on the Internet, join the
v6 generation,
/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  8 07:42:07 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04258; Tue, 8 Aug 95 07:42:07 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04252; Tue, 8 Aug 95 07:41:59 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA26803; Tue, 8 Aug 1995 07:31:07 -0700
Received: from VNET.IBM.COM by venus.Sun.COM (Sun.COM)
	id HAA05505; Tue, 8 Aug 1995 07:31:05 -0700
Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9137;
   Tue, 08 Aug 95 10:30:41 EDT
Received: by RTP (XAGENTA 4.0) id 0627; Tue, 8 Aug 1995 10:30:28 -0400 
Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA17723; Tue, 8 Aug 1995 10:30:30 -0400
Message-Id: <9508081430.AA17723@cichlid.raleigh.ibm.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 494) Max Reassembly Size
Date: Tue, 08 Aug 95 10:30:29 -0500
From: "Thomas Narten" <narten@VNET.IBM.COM>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

At the Stockholm meeting, the question of what the max reassembly size
should be came up again, but resolution of the issue was deferred to
the mailing list (I'm sure someone will correct me if I got that
wrong).

Currently the max MTU is 576 bytes.

It appears that the max reassembly size has also defaulted to this
same value. A number of folks (consensus perhaps?) seemed to agree that
576 was too small, but there was no sense as to what the default value
should be. 1500? 4K? 8K?

There was also some discussion concerning the definition of a new ICMP
"reassembly size too small" error message that receiving hosts could
generate when they got fragments that they couldn't reassemble. The
idea was that a host could send as big a packet as needed, with the
receiver returning an error saying what its reassembly buffer size is
if the packet was too big to be reassembled from its fragments.

After thinking about the error message a bit, I've concluded that it
doesn't really solve the key problem. Suppose that I'm developing
UDP-based protocol 'X'. Message boundaries need to be preserved in
order that transactions be processed all or nothing. If my message is
bigger than 576 bytes, I can't be guaranteed that a path exists that
handles larger packets. Thus, even if I use PMTU, I may be forced to
fragment. I have two options: define a transport level fragmentation
scheme, or use the fragment header.

Suppose I opt for the fragment header approach. If the max reassembly
size a receiver is required to have is only 576, there is no guarantee
that fragmentation will work. Even if some receivers use bigger
reassembly sizes, the fact that some only handle 576 bytes means that
I as a protocol developer must assume that 576 is the largest upper
layer data unit I can transport as one unit. In other words, from a
correctness perspective, my protocol will only work if I can guarantee
that messages fit within in the the 576 byte packet.  That doesn't
leave me much room for actual data, if I use any other headers (ESP,
authentication, etc.).

The end result is that in practice *all* protocols must support
fragmentation at the transport level.  Of course, this is one of the
underlying goals of IPv6. However, in practice, I think this is going
to significantly complicate the migration path to IPv6. We will not be
able to take existing v4 protocols and simply change the size of
addresses while leaving the rest of the packet format essentially the
same.

There are three cases (that I'm aware of) where this issue has come up
already. In Neighbor Discovery, we were able to define packets in such a
way that for all practical purposes, losing one of packet of a message
that must be fragmented isn't a problem. Each option is processed
independently of all others, and an option cannot rely on the absence
or presence of any other options. Thus, we simply send as many
messages as needed until we've sent all the options we wanted to send.
This approach works in ND, but not in all protocols.

For DHCPv6, what to do is still an open issue. In essence, we're
punting by saying it's an implementation issue, or by saying use TCP
if the PMTU isn't big enough. Do we want all protocols to use TCP as
the default backup to handle the case of slightly large messages?
Somehow I don't think so.

Finally, the DNS was cited with a *lot* of concern in Stockholm. It is
a given that many DNS responses will not fit within a 576 packet. If
the max reassembly size is only 576, we've now potentially got *big*
interoperability problems.  If in practice everyone needs to have a
big reassembly size to make the DNS work, we should just mandate it up
front.

In short, I think we are making our life needlessly difficult by
defining a max receive buffer size of 576.  We are essentially forcing
every upper layer protocol to do fragmentation for *correctness*. This
is particularly painful in those cases where 95% of the packets will
be smaller than 576 bytes, and 99.99% will be less 1500 bytes.
Raising the max packet size that can be transmitted succesfully
without an explicit fragmentation facility at the transport protocol
will make life a lot easier for many protocols.

I'd be happy with a max reassembly size of 1500, but would like to
hear the arguments for/against other sizes.

Thomas
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug  8 18:08:09 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04726; Tue, 8 Aug 95 18:08:09 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA04720; Tue, 8 Aug 95 18:07:55 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00917; Tue, 8 Aug 1995 17:56:58 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id RAA01055; Tue, 8 Aug 1995 17:56:54 -0700
Subject: (IPng 495) Re:  Max Reassembly Size
To: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Date: Tue, 8 Aug 1995 20:56:53 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: Dan McDonald <danmcd@sundance.itd.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508090156.aa14572@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

A few things:

1. I think Thomas meant to say that 576 is the MINIMUM MTU, not maximum.

2. Please, please, please don't turn this into an MTU debate.

3. With #2 off my chest, I can say that at first glance, bumping up
   the MINIMUM REASSEMBLY buffer size sounds like a good idea.  I'll have
   to check to see if the reason we (NRL) pushed so hard for 576 MTU is also
   going to be a factor in this reassembly buffer issue.

Thanks!
--
Daniel L. McDonald | Mail: danmcd@itd.nrl.navy.mil OR danmcd@cs.nrl.navy.mil +
Computer Scientist | WWW:  http://wintermute.cs.nrl.navy.mil/danmcd.html     |
Naval Research Lab | The opinions in this note or post are Dan McD.'s alone! |
Washington, DC     | "Rise from the ashes, A blaze of everyday glory" - Rush +
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 07:42:05 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05018; Wed, 9 Aug 95 07:42:05 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05012; Wed, 9 Aug 95 07:41:56 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12768; Wed, 9 Aug 1995 07:31:04 -0700
Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM)
	id HAA20562; Wed, 9 Aug 1995 07:31:04 -0700
Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7726;
   Wed, 09 Aug 95 10:30:41 EDT
Received: by RTP (XAGENTA 4.0) id 1200; Wed, 9 Aug 1995 10:30:39 -0400 
Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA18616; Wed, 9 Aug 1995 10:30:43 -0400
Message-Id: <9508091430.AA18616@cichlid.raleigh.ibm.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 496) IPv6 FAQ
Date: Wed, 09 Aug 95 10:30:42 -0500
From: "Thomas Narten" <narten@VNET.IBM.COM>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

>Ya know folks we have seen this movie and I don't mind seeing it again
>but someone really needs to volunteer to put together the FAQ for IPv6
>so we can send it out when these kind of discussions begin.

I'm willing to put one together. First thing that is needed is a list
of questions. Folks can either send them to the list or to me
privately. I'll put together a proposal and we can go from there.

Thomas
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 08:33:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05050; Wed, 9 Aug 95 08:33:45 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05002; Wed, 9 Aug 95 07:35:55 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12228; Wed, 9 Aug 1995 07:24:58 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id HAA19493; Wed, 9 Aug 1995 07:24:57 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HTV4L57LTC00CQPD@FNAL.FNAL.GOV>; Wed, 09 Aug 1995 09:24:25 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA00465; Wed, 9 Aug 95 09:23:49 CDT
Date: Wed, 09 Aug 1995 09:23:49 -0500
From: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Subject: (IPng 497) Re:  Max Reassembly Size
In-Reply-To: Your message of Tue,
 08 Aug 95 10:30:29 CDT. <9508081430.AA17723@cichlid.raleigh.ibm.com>
To: Thomas Narten <narten@VNET.IBM.COM>
Cc: ipng@sunroof.Eng.Sun.COM
Message-Id: <9508091423.AA00465@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
X-Face: 
 /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

First of all, I think we should be calling it a "minimum", not a
"maximum" reassembly buffer size.  That's how it appears to the IPv6
stack implementor.  To the application developer, it is a maximum
guaranteed size.

As I said in Stockholm, there's no need at all to tie this minimum
size to any medium's MTU.

The argument for bigger required reassembly sizesbuffers is that you
can be sure of getting bigger datagrams through without application-
level hair.  (And in the case of DNS it's generally considered too
late to grow the hair.)

The argument for smaller required sizes is, I suppose, the cost
imposed on the tiny embedded systems -- printers, toasters, or what
have you.

I think 5120 bytes would be a dandy minimum required reassembly
buffer size.  It gives room for a big message (although not a page of
memory in most systems) with generous room for headers.
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 08:53:37 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05084; Wed, 9 Aug 95 08:53:37 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05078; Wed, 9 Aug 95 08:53:25 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19645; Wed, 9 Aug 1995 08:42:32 -0700
Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM)
	id IAA04152; Wed, 9 Aug 1995 08:42:27 -0700
Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
	id AA29382; Wed, 9 Aug 95 11:40:54 EDT
Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1)
	id AA09511; Wed, 9 Aug 95 11:42:07 EDT
Date: Wed, 9 Aug 95 11:42:07 EDT
Message-Id: <9508091542.AA09511@BayNetworks.com>
Received: by karma.engeast (4.1/SMI-4.1)
	id AA12109; Wed, 9 Aug 95 11:41:49 EDT
From: Mike Davis <mdavis@BayNetworks.com>
To: narten@VNET.IBM.COM
Cc: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508091430.AA18616@cichlid.raleigh.ibm.com>
	(narten@VNET.IBM.COM)
Subject: (IPng 498) Re:  IPv6 FAQ
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   Date: Wed, 09 Aug 95 10:30:42 -0500
   From: "Thomas Narten" <narten@VNET.IBM.COM>
   Sender: owner-ipng@sunroof.Eng.Sun.COM
   Precedence: bulk

   >Ya know folks we have seen this movie and I don't mind seeing it again
   >but someone really needs to volunteer to put together the FAQ for IPv6
   >so we can send it out when these kind of discussions begin.

   I'm willing to put one together. First thing that is needed is a list
   of questions. Folks can either send them to the list or to me
   privately. I'll put together a proposal and we can go from there.

   Thomas

My favorite FAQ:  What's a host and what's a router?

--mad
Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 09:34:53 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05151; Wed, 9 Aug 95 09:34:53 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05145; Wed, 9 Aug 95 09:34:45 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA26521; Wed, 9 Aug 1995 09:23:49 -0700
Received: from relay1.pipex.net by mercury.Sun.COM (Sun.COM)
	id JAA13899; Wed, 9 Aug 1995 09:23:44 -0700
From: x.gosselin.rea0803@oasis.icl.co.uk
Received: from Q.icl.co.uk by flow.pipex.net with SMTP (PP);
          Wed, 9 Aug 1995 17:22:58 +0100
Received: from relay1.pipex.net by Q.icl.co.uk (4.1/icl-2.12-server)
	id AB12808; Wed, 9 Aug 95 17:22:07 BST
Received: from getafix.oasis.icl.co.uk by ming.oasis.icl.co.uk over SMTP
	id QAA06125; Wed, 9 Aug 1995 16:09:49 GMT
Message-Id: <9508091557.AA19531@getafix.oasis.icl.co.uk>
Date: Wed, 9 Aug 95 16:57:22 BST
Reply-To: x.gosselin.rea0803@oasis.icl.co.uk
Subject: (IPng 499) RE:  IPv6 FAQ
To: narten@vnet.ibm.com
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk







         OK, lets go for the FAQ :
         there are some :
         
         - What is IPv6 ?
         - What is the difference between IPv4 and IPv6 ?
         - Where can I find an implementation ? ;-)
         - Can I use IPv6 now ?
         - Where are the IPv6 mailing-list archives ?
         - How IPv6 provide security ?
         - Will it be possible to use IPv6 everywhere ? (I mean the crypto 
         restrictions in some countries as France )
         - What is the header architecture ?
         - How enusre the transition from v4 to v6 ?
         - what is the address format ?
         
         That all for today
         Xavier.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 09:55:34 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05172; Wed, 9 Aug 95 09:55:34 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05166; Wed, 9 Aug 95 09:55:26 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29874; Wed, 9 Aug 1995 09:44:28 -0700
Received: from BBN.COM by mercury.Sun.COM (Sun.COM)
	id JAA18836; Wed, 9 Aug 1995 09:43:22 -0700
Received: from aland.bbn.com by BBN.COM id aa16920; 9 Aug 95 12:41 EDT
Received: by aland.bbn.com (8.6.12/3.1.090690-BBN)
	id JAA25184; Wed, 9 Aug 1995 09:42:18 -0700
Message-Id: <199508091642.JAA25184@aland.bbn.com>
To: narten@vnet.ibm.com
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 500) for the IPng FAQ
Reply-To: Craig Partridge <craig@aland.bbn.com>
From: Craig Partridge <craig@aland.bbn.com>
Date: Wed, 09 Aug 95 09:42:17 -0700
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Thomas:
    
    You've taken on a large task!  Here's a contribution.

Craig

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

Question: How is the Flow Label field used?

Answer:

The purpose of the Flow Label field is to identify streams of IPv6 datagrams
that are routed according to special additional state in the routers.
Examples of such special state might be state information provided by RSVP
that allows the flow's datagrams to support guaranteed traffic.

Some of the details of how the Flow Label field will be used are still
under discussion (see RFC 1809).  However it is expected that one use
of the Flow Label field will be to support types of service other than
Best Effort delivery.  The IETF's Integrated Services WG is currently in
the process of standardizing these new types of service and specifications
are expected by early in the fourth quarter of 1995.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 10:24:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05247; Wed, 9 Aug 95 10:24:45 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05241; Wed, 9 Aug 95 10:24:37 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA05260; Wed, 9 Aug 1995 10:13:43 -0700
Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM)
	id KAA26623; Wed, 9 Aug 1995 10:13:43 -0700
Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1347;
   Wed, 09 Aug 95 13:13:17 EDT
Received: by RTP (XAGENTA 4.0) id 1305; Wed, 9 Aug 1995 13:13:12 -0400 
Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA18309; Wed, 9 Aug 1995 13:12:59 -0400
Message-Id: <9508091712.AA18309@cichlid.raleigh.ibm.com>
To: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 501) Re:  Max Reassembly Size
In-Reply-To: (Your message of Wed, 09 Aug 95 09:23:49 EST.)
             <9508091423.AA00465@munin.fnal.gov>
Date: Wed, 09 Aug 95 13:12:58 -0500
From: "Thomas Narten" <narten@VNET.IBM.COM>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

>First of all, I think we should be calling it a "minimum", not a
>"maximum" reassembly buffer size.

Right, as Dan pointed out as well.

>The argument for smaller required sizes is, I suppose, the cost
>imposed on the tiny embedded systems -- printers, toasters, or what
>have you.

The other consideration is balancing the benefits (to upper layer
protocols) of transparent fragmentation against the negatives
associated with transparent fragmentation. (By "transparent", I mean
invisible to the upper layer protocol.) The more fragments, the more
likely performance problems (or worse) will arise.

While 5120 bytes would be nice from the application's perspective, a
PMTU of 576 results in 9 fragments.  This seems like a recipe for
trouble, especially when WANs are involved.  I think it would be wise
to limit the minimum reassembly size to only a few fragments. In cases
where many fragments may result, we *do* want upper layers to do their
own fragmentation. Two end points can always negotiate the use of
larger buffers where it is reasonable to do so (e.g. LANs where sys
admins control both endpoints and have knowledge about the path
between them).

In other words, the min reassembly size should be large enough so that
protocols that reasonably expect their max-sized packets will almost
always be small do not need to do their own fragmentation. Transparent
fragmentation can handle the exceptional large packet in such cases.
At the same time, we don't want to make it so large that protocol
developers rely on transparent fragmentation where inappropriate.

>From this perspective, I'd suggest limiting the min reassembly size to
something like 3-4 times the min packet size (576 bytes).

Thomas
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 10:42:47 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05286; Wed, 9 Aug 95 10:42:47 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05193; Wed, 9 Aug 95 10:09:32 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA02454; Wed, 9 Aug 1995 09:58:29 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id JAA21927; Wed, 9 Aug 1995 09:56:37 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HTV9VBGOOG00CVDB@FNAL.FNAL.GOV>; Wed, 09 Aug 1995 11:56:10 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA01131; Wed, 9 Aug 95 11:55:35 CDT
Date: Wed, 09 Aug 1995 11:55:34 -0500
From: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Subject: (IPng 502) Re:  for the IPng FAQ
In-Reply-To: Your message of Wed,
 09 Aug 95 09:42:17 PDT. <199508091642.JAA25184@aland.bbn.com>
To: Craig Partridge <craig@aland.bbn.com>
Cc: narten@vnet.ibm.com, ipng@sunroof.Eng.Sun.COM
Message-Id: <9508091655.AA01131@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
X-Face: 
 /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Question: How is the Flow Label field used?
> 
> Answer:
> 
> The purpose of the Flow Label field is to identify streams of IPv6 datagrams
> that are routed according to special additional state in the routers....

Or that are routed in the ordinary way, but the Flow Label + Source
Address can help the router look up cached forwarding decisions.


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 14:13:52 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05477; Wed, 9 Aug 95 14:13:52 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05471; Wed, 9 Aug 95 14:13:43 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11572; Wed, 9 Aug 1995 14:02:44 -0700
Received: from BBN.COM by venus.Sun.COM (Sun.COM)
	id OAA14824; Wed, 9 Aug 1995 14:02:30 -0700
Received: from aland.bbn.com by BBN.COM id aa13893; 9 Aug 95 17:00 EDT
Received: by aland.bbn.com (8.6.12/3.1.090690-BBN)
	id OAA25873; Wed, 9 Aug 1995 14:00:50 -0700
Message-Id: <199508092100.OAA25873@aland.bbn.com>
To: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Cc: narten@vnet.ibm.com, ipng@sunroof.Eng.Sun.COM
Subject: (IPng 503) Re: for the IPng FAQ
Reply-To: Craig Partridge <craig@aland.bbn.com>
From: Craig Partridge <craig@aland.bbn.com>
Date: Wed, 09 Aug 95 14:00:49 -0700
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> > The purpose of the Flow Label field is to identify streams of IPv6 datagrams
> > that are routed according to special additional state in the routers....
>
> Or that are routed in the ordinary way, but the Flow Label + Source
> Address can help the router look up cached forwarding decisions.

Well yes, some folks would like to see it used that way.  I'm against the
idea, for a variety of reasons.

Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 14:24:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05492; Wed, 9 Aug 95 14:24:45 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05486; Wed, 9 Aug 95 14:24:36 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13633; Wed, 9 Aug 1995 14:13:43 -0700
Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM)
	id OAA23811; Wed, 9 Aug 1995 14:13:39 -0700
Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6016;
   Wed, 09 Aug 95 17:13:17 EDT
Received: by RTP (XAGENTA 4.0) id 1439; Wed, 9 Aug 1995 17:13:15 -0400 
Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA18386; Wed, 9 Aug 1995 17:13:17 -0400
Message-Id: <9508092113.AA18386@cichlid.raleigh.ibm.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 504) ND: Receive MTU option
Date: Wed, 09 Aug 95 17:13:16 -0500
From: "Thomas Narten" <narten@VNET.IBM.COM>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Note: There are still a small number of unresolved issues in ND. Erik
& I are going to post individual messages on each of them over the
next few days, propose a solution, and solicit feedback.  If no one
objects (strenuously!) to a proposed solution, we'll assume it is OK
and put it in the draft. The goal is to get a new draft out that is
ready for promoting to PS.

In the current draft, Router Advertisements may include an MTU option
specifying the max MTU that all nodes on the link should use.  All
nodes use the same MTU.  The MTU option would be used on links that
lack a well-defined MTU (e.g., token rings).

Earlier Simpson drafts included a per-node receive MTU (RMTU)
option. Any node sending out NA messages could attach an option saying
that its RMTU was XXX. There was no single MTU used by all nodes;
different nodes might have different receive MTUs.

In Stockholm, there was a call for restoring the earlier model (or
something closer to it). As I recall, the discussion for per-node
RMTUs went something like this:

There are configurations in which heterogeneous technologies are
bridged together (e.g., Ethernet and FDDI). In such cases, Ethernet
nodes would have smaller MTUs than FDDI nodes. Forcing a single RMTU
for all nodes would negatively impact performance between nodes
connected (for example) to the same FDDI segment, which could exchange
big packets amongst themselves while sending smaller packets to nodes
attached to Ethernet segments.

However, having per-node RMTUs does not properly handle multicasting.
Because a sender doesn't know which nodes will receive a multicast
packet, it has no way of knowing what the minimum RMTUs of the
receivers are.  Consequently, it was suggested that routers advertise
a global per-link MTU giving the minimum size that all nodes must
accept. Multicast packets could not exceed this MTU, but unicast
packets could, if the sender had received an explicit RMTU from the
neighbor indicating its ability to handle larger packets.

Unfortunately, having per-node RMTUs does not properly handle the case
where two FDDI-attached nodes are separated by Ethernets (with the
small MTU).  A response to this problem was that this is a something
that system administrators could live with; they simply wouldn't set
up such bridged LANs.

Given that per-node RMTUs do not completely solve all problems (or
rather, they leave scenarios where communication will fail), I am not
in favor of changing the MTU option from its current form.

Comments?

Thomas
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug  9 20:17:22 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05700; Wed, 9 Aug 95 20:17:22 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05694; Wed, 9 Aug 95 20:17:13 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA23521; Wed, 9 Aug 1995 20:06:18 -0700
Received: from munnari.oz.au by mercury.Sun.COM (Sun.COM)
	id UAA20623; Wed, 9 Aug 1995 20:06:17 -0700
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
	id AA15489; Thu, 10 Aug 1995 13:04:44 +1000 (from kre@munnari.OZ.AU)
To: "Thomas Narten" <narten@VNET.IBM.COM>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 505) Re:  Max Reassembly Size 
In-Reply-To: Your message of "Tue, 08 Aug 1995 10:30:29 EST."
             <9508081430.AA17723@cichlid.raleigh.ibm.com> 
Date: Thu, 10 Aug 1995 13:04:29 +1000
Message-Id: <9427.808023869@munnari.OZ.AU>
From: Robert Elz <kre@munnari.OZ.AU>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Like Matt, I prefer increasing the guaranteed receive buffer
size (guaranteed reassembly size) as much we consider reasonable
while not completely killing embedded applications (that really
need to be fully compliant, the others I don't care about).

His 5120 suggestion seemed fine to me, 9000 might be nice too
(8K data plus slop for typical headers).

Personally I don't buy the "anti-fragmentation" hangups.   Sure
fragmentation isn't a great idea when it can be avoided, and
protocols like TCP should be dilligent and avoid it all the
time.   Similarly, having fragmentation imposed upon one, by some
intermediate router, is also not good, so making this impossible
in v6 is a great step forward.

However, if a protocol needs to be able to send data units,
which can't be logically divided meaningfully, then it ought
be able to send them.   Its true that if a frag is lost, the
rest of the packet is wasted, but for many applications the
same would be true if the application was doing its own
internal application or transport level level fragmentation.
Unless the application has acks, with sequencing, so it can
ask for "just this bit again please", the effect of losing any
of its fragmented packets will be to toss the lot, and have the
other end re-send them all.   This is no different than having
the fragmentation done inside the IP layer - except costs more
bytes due to having to send transport headers in every fragment
(which may also mean more packets).

To avoid laziness and undue reliance on IP level fragmentation
where better application or transport design would be the
preferred solution, we merely need to be dilligent in watching
those protocol designs, and showing how the messages could be
redesigned to permit smaller data units that can be operated
upon independantly, so that fragmentation can be avoided
where possible.

However, where it's not possible, I don't think that the IP
layer should be legislating the need for transport or application
protocols to invent their own fragmentation schemes to
compensate for IP layer deficiencies.

Next, to get maximum value per message, and since this is
related, or kind of, to the previous topic, I also favour
adding an end-to-end option that can be used to report
the max packet size from one application to another.   Its
semantic should be limited to the "current" transaction, that is,
it should not be used to set some kind of state with respect
to the host sending the option, but be reported up the
stack when a packet containing it is received, indicating to
the application receiving the packet the maximum sized packet
it can use to send its reply - applications with state and
multiple exchanges could retain the value for further replies.

kre
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 10 08:44:09 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05987; Thu, 10 Aug 95 08:44:09 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA05981; Thu, 10 Aug 95 08:43:59 PDT
Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00950; Thu, 10 Aug 1995 08:33:05 -0700
Received: from bridge2.NSD.3Com.COM by Sun.COM (sun-barr.Sun.COM)
	id AA18771; Thu, 10 Aug 95 08:33:03 PDT
Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA27432
  (5.65c/IDA-1.4.4nsd for <ipng@sunroof.eng.sun.com>); Thu, 10 Aug 1995 08:30:29 -0700
Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA06993
  (5.65c/IDA-1.4.4-910730); Thu, 10 Aug 1995 08:28:06 -0700
Message-Id: <199508101528.AA06993@remmel.NSD.3Com.COM>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 506) Re: Max Reassembly Size 
In-Reply-To: Your message of "Thu, 10 Aug 1995 13:04:29 +1000."
             <9427.808023869@munnari.OZ.AU> 
Date: Thu, 10 Aug 1995 08:28:06 -0700
From: Tracy Mallory <tracym@NSD.3Com.COM>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

[In response to Robert, and the general thread,]

I'm definitely on the other side of the fence when it comes to the
maximum guaranteed reassembly size(MGRS). I'd be happy to stick a "strong"
MAY in the spec to suggest that the ability to reassemble up to ~10k
bytes is nice, at least as a configurable capability of the source
code, but I don't agree that every refrigerator, or auto ignition
system, MUST support such large packets. 1518 (I'd allow 2K) seems
just the right number.

If a system runs a protocol that must use largish IP packets, then it
may need to be reconfigured to handle the reassembly of same.
However, I'd like to see some strong evidence that there will be more
than one or two such protocols, which a large number of IP systems
(including my automobile's engine control system) will want to run,
that will make such large MGRS requirement necessary. (I don't buy the
disk/memory-page size arguments.) (If a larger MGRS is needed, then
why not 64k?-) (disk pages are headed in this direction)

I believe that the biggest issue with fragmentation is reassembly
resources. How many MGRS size packets does an implementation need to
be able to reassemble at once? And how does lack of resources get
communicated back to the offending (er, sending;-) host. (a
fragmentation resources failure ICMP message?) Should we require the
sender to randomly back off before sending the next frag-gram?

Seriously, if we are going to legislate significant code and
reassembly resources, then we should be more clear about the various
requirements and parameters. The most interesting values are probably
the number of fragments per packet and the number of concurrent
packets that may be reassembled rather than simply the number of bytes
or buffers. And we SHOULD address the issues of reporting, and acting
on, reassembly resource failure if we really expect to depend on
fragmentation/reassembly functioning well (some folks think that's an
oxymoron;-).

My MGRS requirement would be that all implementations be able
to reassemble exactly one packet of three or four segments (at least
3*576, up to 3*1500 for most systems).

Regards,

Tracy

[I like the e2e packet size option.]

> Like Matt, I prefer increasing the guaranteed receive buffer
> size (guaranteed reassembly size) as much we consider reasonable
> while not completely killing embedded applications (that really
> need to be fully compliant, the others I don't care about).
...
> However, where it's not possible, I don't think that the IP
> layer should be legislating the need for transport or application
> protocols to invent their own fragmentation schemes to
> compensate for IP layer deficiencies.
...
> Next, to get maximum value per message, and since this is
> related, or kind of, to the previous topic, I also favour
> adding an end-to-end option that can be used to report
> the max packet size from one application to another.   Its
> semantic should be limited to the "current" transaction, that is,
> it should not be used to set some kind of state with respect
> to the host sending the option, but be reported up the
> stack when a packet containing it is received, indicating to
> the application receiving the packet the maximum sized packet
> it can use to send its reply - applications with state and
> multiple exchanges could retain the value for further replies.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 10 17:04:22 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06319; Thu, 10 Aug 95 17:04:22 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06313; Thu, 10 Aug 95 17:04:14 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA08766; Thu, 10 Aug 1995 16:53:19 -0700
Received: from mentat.com by mercury.Sun.COM (Sun.COM)
	id QAA16460; Thu, 10 Aug 1995 16:53:16 -0700
Received: from orna.mentat.com ([192.88.122.155]) by mentat.com (4.1/SMI-4.1)
	id AA08427; Thu, 10 Aug 95 16:50:34 PDT
Received: by orna.mentat.com (5.0/SMI-SVR4)
	id AA12684; Thu, 10 Aug 1995 16:50:34 +0800
Date: Thu, 10 Aug 1995 16:50:34 +0800
From: mark@mentat.com (Marc Hasson)
Message-Id: <9508102350.AA12684@orna.mentat.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 507) ICMPv6 pseudo-header
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

We think this is just an editorial comment but at least the author
folks should doublecheck to be sure....  I don't recall this being
mentioned on the list before.

Both the Base spec (draft-ietf-ipngwg-ipv6-spec-02) on pages 25-26 and
the ICMP spec (draft-ietf-ipngwg-icmp-02.txt) on pages 5-8 discuss the
ICMPv6 pseudo-header calculation.  But they are somewhat inconsistent
with each other.  They specify different orderings of the payload
length and the "next hdr" is in a different spot.  There's also some
differences in the explanatory texts, just due to having 2 copies of
this.  My belief is that both descriptions are technically correct and
will give the same checksum result.  However, having the 2 descriptions
leads one to think there's something different between the two and may
unnecessarily encourage separate pseudo-header calculation routines to
be implemented or mistakes to be made.  And why should future implementers
spend *any* time thinking about those differences in the documents?

So, if I'm correct that both procedures give identical results I'd like
to see one of them pulled.  My current inclination is to pull the one
from the ICMP spec since then *all* ULPs would be described the same
way in the one Base spec.  A reference to the Base spec is all we
should need in ICMP for this.  The ICMP spec's "checksum calculation
rules" (d) should also be moved to the Base spec since it clearly
describes an important rule for computing the checksum (initialize it
to zero!) which the Base spec didn't mention.
                        
                         
   -- Marc --

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 10 20:03:51 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06421; Thu, 10 Aug 95 20:03:51 PDT
Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06415; Thu, 10 Aug 95 20:03:43 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id TAA04939; Thu, 10 Aug 1995 19:52:49 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id TAA23326; Thu, 10 Aug 1995 19:52:25 -0700
Date: Thu, 10 Aug 1995 19:52:25 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508110252.TAA23326@bobo.Eng.Sun.COM>
To: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 508) Re:  On source address determination
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> I can see a basic set of rules where:
> 
> 	1. If link-local dest, use link-local src.
> 	2. If v4-compatible dest, use v4-compatible src.
> 	3. If site-local dest, use site-local src.
> 	4. Otherwise, pick "best" source on that interface.

Those rules look reasonable as long as you handle the case when the
interface doesn't have a v4-compatible or site-local address.

> I have a few ideas on how to implement #4, but I'll leave those out for now.

I'd like to hear more about your ideas.

> One other thing, can you imagine doing those four steps on every outgoing
> d-gram?  I didn't think so.  I *CAN* imagine, however, doing those four
> steps when creating a new next-hop or neighbor cache entry.  (Sometimes,
> especially in the case of neighbor caches, the correct source address just
> falls out.  An implementation detail of mine, and probably others who are
> BSD-ish I guess.)

Sounds like the best approach.

  Erik


------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 11 08:55:37 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06639; Fri, 11 Aug 95 08:55:37 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06633; Fri, 11 Aug 95 08:55:28 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA05097; Fri, 11 Aug 1995 08:44:29 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id IAA24018; Fri, 11 Aug 1995 08:44:25 -0700
Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA22120; Fri, 11 Aug 1995 08:35:41 -0700
Received:  from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
	id AA11386; Fri, 11 Aug 1995 11:35:39 -0400
Received: by netrix.lkg.dec.com; (5.65/1.1.8.2/28May95-0415PM)
	id AA16920; Fri, 11 Aug 1995 11:35:35 -0400
Date: Fri, 11 Aug 1995 11:35:35 -0400
From: Dan Harrington <dan@lkg.dec.com>
Message-Id: <9508111535.AA16920@netrix.lkg.dec.com>
To: narten@VNET.IBM.COM
Subject: (IPng 509) Re:   ND: Receive MTU option
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Hi Thomas,

> [...]
> Unfortunately, having per-node RMTUs does not properly handle the case
> where two FDDI-attached nodes are separated by Ethernets (with the
> small MTU).  A response to this problem was that this is a something
> that system administrators could live with; they simply wouldn't set
> up such bridged LANs.
> [...]
> Comments?

Just a quick data point...In the CLNP implementation I work on, we deal
with this issue by keeping a reverse path cache which includes a test of
the datalink header to see if the source of a given packet is On-Ring.
If so, the full FDDI blocksize can be utilized to exchange data with that
particular destination.  Otherwise the lower Ethernet blocksize must be used.

This seemed more reliable than trusting folks to never configure the
dreaded dumbbell LAN...it also doesn't require an MTU option.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 11 14:15:31 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06775; Fri, 11 Aug 95 14:15:31 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06769; Fri, 11 Aug 95 14:15:17 PDT
Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21011; Fri, 11 Aug 1995 14:04:19 -0700
Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM)
	id AA12991; Fri, 11 Aug 95 14:03:57 PDT
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa23811;
          11 Aug 95 21:57 GMT
To: ipsec@ans.net
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 510) My thoughts on three timely IPsec issues...
Date: Fri, 11 Aug 1995 16:57:49 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508112157.aa23811@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


	As I had mentioned on the IPsec developers' list, I had some
specific thoughts on some IP security issues that are currently being
discussed, but I wanted to wait until I had built some code before
making them known because I wanted to be sure that my ideas were
implementable. I have, it mostly works, there are no outstanding
questions as to whether something is doable or not, so I have prepared
my thoughts into three messages to form a long tirade. I am carbon-
copying this and these to the IPng list, because at some point, in order
to be IPng spec-compliant, all IPng implementations will have to do
security processing, so these issues need to be thought about by IPng
people.

	The first message I will send (part one) is some general
background discussion.

	The second message I will send (part two) is on IPv4 options
that we can't handle. IPng people may want to skip this one, but I
believe that some of the discussion is relevant.

	The third message I will send (part three) is a detailed
listing of my conclusions as to the variance/invariance/predictability
of every defined field in every IP (IPv4 and IPv6) network-level
header I could find a spec for.

	These messages are intended to prompt discussion. Please
direct this discussion to the <ipsec@ans.net> mailing list, NOT the
<IPng@sunroof.eng.sun.com> mailing list. Unfortunately, I will not
have very good network access for the next month, so I will not be
able to participate in this discussion as much as I would like to.

							-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 11 14:16:18 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06797; Fri, 11 Aug 95 14:16:18 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06786; Fri, 11 Aug 95 14:16:02 PDT
Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21149; Fri, 11 Aug 1995 14:04:59 -0700
Received: from  by Sun.COM (sun-barr.Sun.COM)
	id AB12991; Fri, 11 Aug 95 14:04:48 PDT
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa23828;
          11 Aug 95 21:59 GMT
To: ipsec@ans.net
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 511) Part Two: IPv4 Options We Can't Handle
Date: Fri, 11 Aug 1995 16:59:12 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508112159.aa23828@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


	I have heard several statements on this issue that I disagree
with, and now I have working (well, mostly ;) code that I can use to back
up my disagreement. 

	The first thing I've heard that I disagree with is that we should
not include IPv4 options in the IPv4 authentication computation. There are
two main reasons given:

	1. If we get an option that we can't process, we must ignore
		it (RFC1122). If we can't process it, though, we don't
		know whether the fields are invariant, so we might be
		dropping the packet solely because we can't process
		the option, which conflicts with RFC1122.

	2. Routers might insert, remove, or re-order options.

	I will discuss the latter one first. When routers mess with the
options attached to the packet, you are guaranteeing that the packet does
not have intermediate authenticity because the packet at some points along
its path of travel is not the same as the packet as sent by the sender.
Therefore, whenever routers modify the packet in any way other than the
modification of specific variant fields, you do not have intermediate
authenticity anymore at some or all points along your path. In the
context of my second example, C may legitimately insert an IPSO option,
but if E or F is the router stripping that option and restoring the packet,
the packet will not have intermediate authenticity at D because the packet
is not what A sent or what A intends B to receive.

	However, end-to-end authenticity guarantees are not mutually
exclusive with routers that modify options *as long as they put things
back the way they found them somewhere along the line*. In the context of my
second example, C may legitimately insert an IPSO option so long as D, E, or
F removes it and restores the packet to its original form. As long as it
does, B will see the packet as A intended it to be seen, and it is therefore
end-to-end authentic. If C inserts the IPSO option and no router removes it,
the packet at B is not end-to-end authentic because the packet at B is not
what A sent or intended B to see. It is important that the AH verification
procedure fail in this case exactly because the packet has been modified
in transit. AH has no concept of good or bad modifications, but it has a
strict concept of authenticity. This packet is not authentic because it has
been modified.

	One of our resident experts on routers that insert, examine, and remove
IPSO options into IPv4 packets tells me that "no known router ships configured
to perform IPSO modifications and that such modifications only happen if the
router admin actively configures the router to do so. Further, IPSO
modifications are directly security-relevant -- we do want packets with
intermediate IPSO modifications to fail end-to-end authenticity checks".

	Now to discuss the first problem. A number of interpretations of
RFC1122 have been posted in this discussion, but I would like to work from
what RFC1122 says about options you can't process:

	"The IP and transport layer MUST each interpret those IP
	 options that they understand and silently ignore the
	 others."

	The problem here is one of how we can determine whether fields of
an option are variant or not. I think that we all can agree that if we know
how to handle an option, we can presumably get some sort of consensus on what
is and isn't variant and implement that. So the question is really what
"silently ignore" means. The reason I quote the text here is because most
people have substituted the word "skip" for "silently ignore" and operated
with the assumption that this is the only legitimate interpretation. I
disagree. Consider transport headers and transport data. They're not network-
level, we have no right at the AH level to mess with them. What do we do with
them for AH computation? We run the cryptographic checksum straight over them
with no variance substitutions. Therefore, I believe that a reasonable
definition of "ignore" is also to simply run the cryptographic checksum 
straight over the options we can't handle with no variance substitutions.
Another possibility, which I don't recommend, is to zero out the options
we can't process except for their type and length fields (more on this
later).

	There are three classes of unknown options for purposes of
evaluating which definition of "silently ignore" is most reasonable.
The first are unpredictably variant options. For example, the timestamp
option. The second are invariant options. For example, the IPSO option.
The third are predictably-variant options. For example, the SSRR option.

	Fifth assertion: If both sides cannot process an option and both
sides do the same thing in cases of unknown options (either skip/omit,
zero, or blind-hash), all three methods will work. Only in the last
case, however, will the contents of the option be protected from
modification in transit. In this case, the best option is a blind-hash.

	Now we have the case, which I consider more common and more
interesting, where one side does not know how to process the option
but the other does. If you "skip over" (omit from computation) options
you can't handle, you lose for all three cases because the side that
does know how to process the option will include data, some of which
may be zeroed out, from the option at that position in its computation.

	If you zero out options you can't process except for the type and
length, you win for fields of the first class. In the case of the second class,
the field will be hashed blindly as its value, and you will lose if its value
doesn't happen to be zero. In the case of the third class, the field has a
value that is computed for authentication to match what it would look like at
the receiver -- if it doesn't happen that the value should be zero, you lose.

	If you blindly hash options you can't process, you lose for the
first class unless the values you blindly hash happen to be zero. You never
lose in the second class. You lose in the third class unless you are the
receiver, in which case the values you see and hash are also what you're
supposed to see at the receiver (because you ARE the receiver).

	Skipping over the options you can't process is clearly bad to me
because you always lose if one of the ends can process the option.
Coincidental zeros aside, you lose in two of the three cases if you
zero out the fields other than type and length. Coincidental zeros aside,
you lose in one case all the time and another if you are not the
receiver if you blindly hash the options you can't process.

	Sixth assertion: Blindly hashing the value gives you clearly better
security if both sides can't process an option and slightly better
security if one side can't process an option. It also provides for a simpler
implementation versus hashing the type and length and zeroing the rest,
which would otherwise be the next best way to handle the problem of IPv4
options you can't process.

	For purposes of processing IPv4 options when you don't know how,
keep in mind this statement from RFC1122: "For this purpose, every IP option
except NOP and END-OF-LIST will include a specification of its own length."
RFC791 says that there are two forms an IPv4 option can take: "Case 1: a
single octet of option-type. Case 2: An option-type octet, an option-length
octet, and the actual option-data octets.". 

	Seventh assertion: There are no options of case 1 that make sense
other than NOP and END-OF-LIST, which all non-brain-damaged systems can
handle. Therefore, all options that you do not know how to process will be
of case 2, and you can therefore determine the length of options you can't
handle. This allows you to get back on track when an unknown option is
followed by a known option.

	You're walking with a safety-net here -- in the event that this
assertion is not true, you will eventually either run into an option that
looks legitimate or come into a situation where you are out of option data.

	Eighth assertion: If you encounter an out-of-option-data situation
or encounter the END-OF-LIST option with more data between it and the end
of the option space data (the IP header length with the size of the base IP
header subtracted), you treat all offending data as an unknown option and,
therefore, you blindly hash it. 

	If you run into, for instance, a source route, and that source route's
length points outside the option space data length (computed as
aforementioned), something is wrong with the source route and you can't process
it properly. If you know with certainty that the option is bad, immediately
drop the packet. There is no point in computing the hash over a known-bogus
packet and/or passing it on to the next hop. 

	Padding between the END-OF-LIST option and the end of option space data
"is zero" [RFC791]. This data should be blind-hashed.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 11 14:16:48 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06809; Fri, 11 Aug 95 14:16:48 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06798; Fri, 11 Aug 95 14:16:23 PDT
Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21241; Fri, 11 Aug 1995 14:05:19 -0700
Received: from  by Sun.COM (sun-barr.Sun.COM)
	id AB12991; Fri, 11 Aug 95 14:05:10 PDT
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa23834;
          11 Aug 95 21:59 GMT
To: ipsec@ans.net
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 512) Part Three: Field Variance Analysis
Date: Fri, 11 Aug 1995 16:59:42 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508112159.aa23834@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


	The second thing that I've heard that I disagree with is that the
IP header has so many more variant fields and fields that aren't critical
to security that we should just use a pseudo-header. One thing in these
arguments I disagree with is the definition of "critical to security".

	Ninth assertion: Fields that can be used for denial-of-service
attacks must be authenticated so that the denial-of-service attack can
be detected and logged.

	Even if mucking with a field can't be used to get into a system,
steal a connection, or something direct like that, it frequently has the
ability to cause other denial-of-service situations. When any denial-of-
service attack is in progress, you need to be able to know this in order
to stop it. Fields that aren't critical to system security but could be
modified to create a denial-of-service attack should still be authenticated
for the sole purpose of detecting that attack.

	Also, I'm not a cryptographer and I don't play one on TV, but it
would seem to me that known nonzero but not really important values are
probably better than zero values and should not be worse. It would seem
to me that information of that sort should be stirred into the pot just to
have some nonzero bits in the stew. Someone who knows more about cryptography
and cryptographic checksums could offer better input on this subject, but,
unless someone with more crypto experience can explain otherwise, I am
working from the assumption that nonzero fields are better than zero fields.

	Some discussion should be given to reserved fields. Currently, I
believe that reserved fields should be included in the hash for exactly
the same reason unknown option fields should be. The argument and cases
is exactly the same.

	That all said, this is what I concluded for variance:

	Legend:
		Classes:
			Invariant = If this field changes, the packet is
					not authentic
				(C) = Changed by some routers. By definition,
					however, the packet is not actually
					authentic if this field is changed
					and not changed back before the next
					AH check.
			Variant = If this field changes, the packet is
					still authentic
					(L) = Due to layering (e.g., of 
						fragmentation below AH)
					(T) = Due to transit
			Predictable = This field changes deterministically,
					so we can figure out what it will
					look like at the receiver
		Actions:
			Hash = Run straight through hash
				(R) = Redundant, i.e., should be authentic
					by virtue of getting to AH processing,
					but we still want a crypto guarantee
			Zero = Run a same-size zero block through hash
			Roll = "Roll-forward"/compute how it would look at
				the receiver after re-assembly, run result
				through hash

		Other Symbols:
			(deprecated) = Obsolete or never caught on. If I
				label your favorite option deprecated, don't
				think I'm trying to slam it. It's just that
				I don't know of any system that uses it.
				You can probably get away with not processing
				deprecated options, but I wouldn't recommend
				that you do so.
			(*)(+) = Indicate footnotes follow with more info.

==== IPv4 ====

IPv4 Header: [RFC791]

	Field		Size	Class		Action

	Version		4 bits	Invariant	Hash (R)
	IHL		4 bits	Invariant (C)	Hash (R)
	TOS		8 bits	Invariant (C)	Hash
	Total length	16 bits	Invariant (C)	Hash (R)
	Identification	16 bits	Invariant	Hash
	Flags:
	  Reserved	1 bit	Invariant	Hash
	  DF		1 bit	Invariant	Hash
	  MF		1 bit	Predictable	Roll (=Zero)
	Fragment off.	13 bits	Predictable	Roll (=Zero)
	Time to Live	8 bits	Variant (T)	Zero
	Protocol	8 bits	Invariant	Hash (R)
	Header Checksum	16 bits	Variant (L)	Zero (R)
	Source Address	32 bits	Invariant	Hash
	Destination Ad.	32 bits	Predictable(*)	Roll(*)

	(*) If a source route is present and the pointer is less than the
		length (indicating that this is not the final destination),
		the Destination Address field must be filled in with the
		last destination address in the source route's list.

IPv4 End of Option List Option: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash

IPv4 No Operation: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash

IPv4 Security Option: [RFC791] (*) (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Security (S)	16 bits	Invariant	Hash
	Compartments(C)	16 bits	Invariant	Hash
	Handling Rst(H)	16 bits	Invariant	Hash
	Trans. Ctl(TTC)	24 bits	Invariant	Hash

	(*) This option has the same type value (130) as the IPv4
		Basic Security option [RFC1108].

IPv4 Loose/Strict Source and Record Route options: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Pointer		8 bits	Predictable(*)	Roll
	Data		var.	Predictable(+)	Roll

	(*) At the final destination, the Pointer will be equal to (Length+1)
	(+) The algorithm for rolling source route data is:
		0. If Pointer > Length, don't roll (you have it already)
		1. Hash up to the octet before the one pointed to by Pointer
		2. Hash the destination address in the IP header
		3. If (Pointer + (size of dest address)) > Length, you're done
		4. Hash from Pointer to (Length - (size of the dest. address))

IPv4 Record Route option: [RFC791]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Pointer		8 bits	Variant		Zero
	Data		var.	Variant		Zero

IPv4 Stream Identifier option: [RFC791] (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash	
	Stream ID	16 bits	Invariant	Hash

IPv4 Internet Timestamp option: [RFC791] (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Pointer		8 bits	Variant		Zero
	Overflow	4 bits	Variant		Zero
	Flag		4 bits	Invariant	Hash
	Data		var.	Variant		Zero

IPv4 Probe/Reply MTU options: [RFC1063] (*) (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Value		16 bits	Variant		Zero	

	(*) RFC1700, Assigned Numbers, lists RFC1191 as being the
		current specification for these options. RFC1191 is
		the current specification for Path MTU Discovery
		and obseletes RFC1063, but it does not mention this
		option at all. RFC1063 defines the latest version
		of this options.

IPv4 Basic Security option: [RFC1108] (*)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Classification	8 bits	Invariant	Hash
	Protection Auth	var.	Invariant	Hash

	(*) This option has the same type value (130) as the IPv4
		Security option [RFC791].

IPv4 Extended Security option: [RFC1108]

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Add. Info Fmt.	8 bits	Invariant	Hash
	Add. Info	var.	Invariant	Hash

IPv4 Traceroute option: [RFC1393] (deprecated)

	Field		Size	Class		Action

	Type		8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	ID Number	16 bits	Invariant	Hash
	Outbound Hop C.	16 bits	Variant		Zero
	Return Hop Cnt.	16 bits	Variant		Zero
	Originator IP	32 bits	Invariant	Hash

==== IPv6 ====

IPv6 Header: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Version		4 bits	Invariant	Hash (R)
	Priority	4 bits	Invariant	Hash
	Flow Label	24 bits	Invariant	Hash
	Payload Length	16 bits	Invariant	Hash (R)
	Next Header	8 bits	Invariant	Hash (R)
	Hop Limit	8 bits	Variant (T)	Zero
	Source Address	128 bit	Invariant	Hash
	Destination Ad.	128 bit	Predictable(*)	Roll(*)

	(*) If a source route is present and the pointer is less than the
		length (indicating that this is not the final destination),
		the Destination Address field must be filled in with the
		last destination address in the source route's list.

IPv6 Hop-by-Hop/Destination Options Headers: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Hdr Ext Len	8 bits	Invariant	Hash
	Option Data	var.	var.(*)		var.(*)

	(*) If the third-highest-order bit in the Option Type is set,
		the Option Data MUST be Zeroed. If the third-highest-order
		bit in the Option Type is not set, you must either Hash
		or Roll, depending on the option.

IPv6 Pad1 Option: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Option Type	8 bits	Invariant	Hash

IPv6 PadN Option: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Option Type	8 bits	Invariant	Hash
	Option Length	8 bits	Invariant	Hash
	Option Data	var.	Invariant	Hash

IPv6 Jumbo Payload Option: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Option Type	8 bits	Invariant	Hash
	Option Length	8 bits	Invariant	Hash
	Option Data	32 bits	Invariant	Hash

IPv6 Routing Header: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Routing Type	8 bits	Invariant	Hash
	(*)		(*)	(*)		(*)

	(*) More data follows depending on type.

IPv6 Routing Header Type 0: [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Routing Type	8 bits	Invariant	Hash
	Num Addrs	8 bits	Invariant	Hash
	Next Addr	8 bits	Predictable(*)	Roll(*)
	Reserved	8 bits	Invariant	Hash
	Strict/Loose	24 bits	Invariant	Hash
	Addresses	var.	Predictable(+)	Roll(+)

	(*) At the final destination, the Next Addr field will be equal to
		the Num Addrs field
	(+) The algorithm for rolling source route data is:
		0. If Next Addr = Num Addrs field, don't roll (you have it)
		1. Hash Address[0] through Address[Next Addr - 1]
		2. Hash the destination address in the IPv6 header
		3. If (Next Addr + 1) > Length, you're done
		4. Hash from Address[Next Addr] through Address[Num Addrs - 2]

IPv6 Fragment Header: (*) [draft-ietf-ipngwg-ipv6-spec-02]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Reserved	8 bits	Invariant	Hash
	Fragment Offset	13 bits	Predictable	Roll (=Zero)
	Res		2 bits	Invariant	Hash
	M flag		1 bit	Predictable	Roll (=Zero)
	Identification	32 bits	Predictable	Hash

	(*) This is academic, since you MUST not ever authenticate
		fragments except when the fragments are inside a
		tunnel (AH processing is done before fragmentation
		and after re-assembly).

==== IPv4/IPv6 Common ====

IP Authentication Header: (*) [RFC1826]

	Field		Size	Class		Action

	Next Header	8 bits	Invariant	Hash
	Length		8 bits	Invariant	Hash
	Reserved	16 bits	Invariant	Hash
	Security Param.	32 bits	Invariant	Hash
	Auth. Data	var.	Variant (L)(+)	Zero

	(*) Yes, you have to authenticate the authentication header.
	(+) You have to zero this field or you get a chicken-and-egg
		problem.

IP Encapsulating Security Payload: [RFC1827]

	Field		Size	Class		Action

	Security Associ	32 bits	Invariant	Hash
	Opaque Transfor var.	Invariant(*)	Hash(*)

	(*) Unless the authenticating point participates in the ESP
		key management, it doesn't know what the transform.
		Treating all of this data as opaque seems to be the
		most reasonable thing given the nature of the data
		and the currently defined DES-CBC transform.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 11 14:27:09 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06830; Fri, 11 Aug 95 14:27:09 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA06824; Fri, 11 Aug 95 14:27:00 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA23058; Fri, 11 Aug 1995 14:16:05 -0700
Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM)
	id OAA22325; Fri, 11 Aug 1995 14:16:03 -0700
Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com
	with SMTP id RAA01242 for <ipng@sunroof.eng.sun.com>; Fri, 11 Aug 1995 17:15:27 -0400
Message-Id: <199508112115.RAA01242@dylan.mindspring.com>
X-Sender: sthomas@mindspring.com
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Aug 1995 17:01:33 -0400
To: ipng@sunroof.Eng.Sun.COM
From: Stephen Thomas <sthomas@mindspring.com>
Subject: (IPng 513) IPv4-{compatible,mapped} Class D addresses
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Gentle Readers:

Since draft-ietf-ipngwg-addr-arch-03.txt seems to be silent on this
one, I bring it up as a question. Are the embedded IPv4 address formats
intended to support Class D addresses as well as unicast ones?

I rather hope not, as that requires more than simply checking the
8-bit format prefix to recognize a multicast address.

If I may be so bold, could we set aside the 16-bit format prefix
FFFF::/16 for embedded IPv4 class D addresses? That would allow
us to preserve checksums in the conversion from IPv4 to IPv6. In
a manner analogous to the current standard, we could use

  FFFF::/96     for ClassD-compatible IPv6 addresses
  FFFF::FFFF/96 for ClassD-mapped IPv6 addresses

Am I missing something obvious?

--Stephen

________________________
Stephen A. Thomas
4397 Windsor Oaks Circle
Marietta, GA  30066-2387
E-mail: s.thomas@acm.org

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sat Aug 12 14:12:59 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07350; Sat, 12 Aug 95 14:12:59 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07344; Sat, 12 Aug 95 14:12:49 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA24805; Sat, 12 Aug 1995 14:01:52 -0700
Received: from garnet.berkeley.edu by mercury.Sun.COM (Sun.COM)
	id OAA20077; Sat, 12 Aug 1995 14:01:53 -0700
From: mendes@garnet.berkeley.edu
Received: by garnet.berkeley.edu (8.6.10/1.33r)
	id OAA18727; Sat, 12 Aug 1995 14:01:52 -0700
Date: Sat, 12 Aug 1995 14:01:52 -0700
Message-Id: <199508122101.OAA18727@garnet.berkeley.edu>
To: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Re:  Max Reassembly Size

I'd like to offer an opinion, albeit as an "outsider," since I've only followed
the working group by reading minutes and drafts.  As I've read the exchanges
on the max reassembly size and questions about which layer should fragment
large messages, I wonder about the role for IPv6.

My feeling is that IPv6 ought to be designed to optimize performance of the
Internet for traditional message/file transfers, as well as the real-time
multimedia applications coming down the pike in a few years.  It seems to me
that specialized embedded systems, while they may want to use TCP/IP or UDP/IP
stacks, should not dictate the design of a new protocol whose primary purpose
is to solve some tough problems for the Internet community and computer
networks generally.

Embedded systems designers surely can design their own upper layer applications
to handled buffer size limits, and, with the price of memory relatively cheap,
ought to be able to included 5K to 10K for receive buffers if that's what the
protocol mandates.  Or, they can use 576 byte buffers by designing their 
applications appropriately.

I may be out of line, but I hope you won't let the tail (small embedded systems)
wag the dog here.

Jerry Mendes
Principal Consultant
DataComm Insights
Mill Valley, CA
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 13 12:53:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07589; Sun, 13 Aug 95 12:53:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07583; Sun, 13 Aug 95 12:53:27 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA24752; Sun, 13 Aug 1995 12:42:29 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id MAA04277; Sun, 13 Aug 1995 12:42:29 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA12938; Sun, 13 Aug 1995 12:38:38 -0700
Received: by xirtlu.zk3.dec.com; id AA15521; Sun, 13 Aug 1995 15:38:34 -0400
Message-Id: <9508131938.AA15521@xirtlu.zk3.dec.com>
To: Robert Elz <kre@munnari.OZ.AU>
Cc: "Thomas Narten" <narten@VNET.IBM.COM>, ipng@sunroof.Eng.Sun.COM,
        bound@zk3.dec.com
Subject: (IPng 514) Re: Max Reassembly Size 
In-Reply-To: Your message of "Thu, 10 Aug 95 13:04:29 +1000."
             <9427.808023869@munnari.OZ.AU> 
Date: Sun, 13 Aug 95 15:38:28 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

I think this is a good discussion but can we just select consensus on
what the need is for max reassembly and not get into whether its done at
transport or ip layers, etc.  One persons layer is another persons
module in the networking kernel.  Our job is to specify standards not
how implementations make the standards work and interoperate with other
implementations of the standard.

576 is too small.  1500 sounds right.  At the TCP/IP EXPO I was
connecting to our v6 node and found that I could not get a response.
Earlier that day both HP and Mentat were able to telnet.v6 into the
machine and see my script for netstat.v6 routing tables and sockets
being used.  Jumped into the node and ran tcpdump at both ends and saw
that we were sending 1480 size packets and they were being fragmented.
I will add that there was a bogus router on the Internet timing out and
could not seem to send more than one fragment (so I experienced at 1:30
a.m. that fragmentation is bad for your health and my sleep).  dbx'd
the nodes kernel and force if_net ipmtu to 576 for our tunnel interface
(tna0) as we were remote and could not change the code.  All worked fine.  

But.... NFS folks would say we need at least need 8K like we need large mbufs
in some implementations of TCP/IP.

/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 13 13:23:34 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07612; Sun, 13 Aug 95 13:23:34 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07606; Sun, 13 Aug 95 13:23:26 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA25527; Sun, 13 Aug 1995 13:12:29 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id NAA05713; Sun, 13 Aug 1995 13:12:29 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA11979; Sun, 13 Aug 1995 13:06:37 -0700
Received: by xirtlu.zk3.dec.com; id AA15682; Sun, 13 Aug 1995 16:06:34 -0400
Message-Id: <9508132006.AA15682@xirtlu.zk3.dec.com>
To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark)
Cc: ipng@sunroof2.Eng.Sun.COM, bound@zk3.dec.com
Subject: (IPng 515) Re: On source address determination 
In-Reply-To: Your message of "Thu, 10 Aug 95 19:52:25 PDT."
             <199508110252.TAA23326@bobo.Eng.Sun.COM> 
Date: Sun, 13 Aug 95 16:06:28 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Erik,

>> I can see a basic set of rules where:
>> 
>> 	1. If link-local dest, use link-local src.
>> 	2. If v4-compatible dest, use v4-compatible src.
>> 	3. If site-local dest, use site-local src.
>> 	4. Otherwise, pick "best" source on that interface.

>Those rules look reasonable as long as you handle the case when the
>interface doesn't have a v4-compatible or site-local address.

Reasonable yes the only way to do it NO.  Don't want to see this in ND
spec as we will never get to proposed standard.  For sure we don't want
to do this on every connection it won't perform.  I think a mask on
whatever one is doing for a routing table will work fine and cheap but
this is an implementation issue.  You can always use a global address if
you have one.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 13 13:37:48 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07636; Sun, 13 Aug 95 13:37:48 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07630; Sun, 13 Aug 95 13:37:40 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA26381; Sun, 13 Aug 1995 13:26:40 -0700
Received: from noao.edu by mercury.Sun.COM (Sun.COM)
	id NAA06448; Sun, 13 Aug 1995 13:26:37 -0700
Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102)
	id AA15570; Sun, 13 Aug 95 13:26:24 MST; for ipng@sunroof.eng.sun.com
Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14)
	id AA11632; Sun, 13 Aug 95 13:26:23 MST; for ipng@sunroof.eng.sun.com
Message-Id: <9508132026.AA11632@gemini.tuc.noao.edu>
From: rstevens@noao.edu (Richard Stevens)
Date: Sun, 13 Aug 1995 13:26:23 -0700
Reply-To: Richard Stevens <rstevens@noao.edu>
X-Phone: +1 520 297 9416
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 516) IPv6 resolver questions
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Couple of simple questions that I couldn't find answered in the drafts
or in the INRIA implementation.

- Are link-local addresses intended to appear in the DNS (an AAAA record)?

- If I have an IPv6 provider-based unicast address and an IPv4-compatible
  address (2 AAAA records, probably quite typical for the coming years)
  is there a preferred order in which they should be returned by a resolver?
  If the DNS client and the provider-based address are on the same link,
  then returning the provider-based address allows pure IPv6 to be used.
  If the IPv4-compat address is returned first, then the communication will
  be encapsulated in IPv4 datagrams.

	Rich Stevens  (rstevens@noao.edu)
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 02:02:15 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07849; Mon, 14 Aug 95 02:02:15 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07843; Mon, 14 Aug 95 02:02:02 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19154; Mon, 14 Aug 1995 01:51:04 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id BAA16804; Mon, 14 Aug 1995 01:51:02 -0700
Message-Id: <m0shvTJ-00014aC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 517) Re: Max Reassembly Size
To: bound@zk3.dec.com
Date: Mon, 14 Aug 1995 10:06:13 +0100 (BST)
Cc: kre@munnari.OZ.AU, narten@VNET.IBM.COM, ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508131938.AA15521@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 13, 95 03:38:28 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> But.... NFS folks would say we need at least need 8K like we need large mbufs
> in some implementations of TCP/IP.

Fixing VFS performance problems is not part of the IPv6 networking brief to
my understanding. If we do go to 8K its probably better to pick a bit under
a multiple of a common page size because many fast memory allocators are
page based, and its common to include internal admin info and the packet in
one block to avoid the overhead of two allocations. 

At 576 bytes or 1500 bytes this is hardly an issue, at 8K,16K.. it starts to
become one

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 06:28:26 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07917; Mon, 14 Aug 95 06:28:26 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07911; Mon, 14 Aug 95 06:28:17 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA27657; Mon, 14 Aug 1995 06:17:18 -0700
Received: from crl.dec.com by mercury.Sun.COM (Sun.COM)
	id GAA04515; Mon, 14 Aug 1995 06:17:13 -0700
From: bound@zk3.dec.com
Received: by crl.dec.com; id AA26186; Mon, 14 Aug 95 09:10:20 -0400
Received: by xirtlu.zk3.dec.com; id AA24973; Mon, 14 Aug 1995 09:07:45 -0400
Message-Id: <9508141307.AA24973@xirtlu.zk3.dec.com>
To: Richard Stevens <rstevens@noao.edu>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 518) Re:  IPv6 resolver questions 
In-Reply-To: Your message of "Sun, 13 Aug 95 13:26:23 PDT."             <9508132026.AA11632@gemini.tuc.noao.edu> 
Date: Mon, 14 Aug 95 09:07:38 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>- Are link-local addresses intended to appear in the DNS (an AAAA record)?

Its not really prevented and could be done.  They are an address for a
node so its possible.  In the specs we never say what you must create
DNS records for or not to create.  At TCP/IP EXPO we found putting all
addresses in /etc/hosts (like server but did not want to put AAAA
records on EXPO NS Server) a good idea.  What we did is use different
names like node-local, node-compatible, node-direct-v6, etc....  So one
could do this:  

   trying to get to node ALPHA... so in hostname2addr you could pass
   ALPHA-LOCAL which would get you back the link local address FE80...
   Or I guess you could mask the returned address list for FE80.

>- If I have an IPv6 provider-based unicast address and an IPv4-compatible
>  address (2 AAAA records, probably quite typical for the coming years)
>  is there a preferred order in which they should be returned by a resolver?
>  If the DNS client and the provider-based address are on the same link,
>  then returning the provider-based address allows pure IPv6 to be used.
>  If the IPv4-compat address is returned first, then the communication will
>  be encapsulated in IPv4 datagrams.

Nope.  This is one of the hell effects of allowing mulitple addresses
per name but I digress.  A ::16.123.12.3 address does not imply "pure
IPv6" is not being used.  What could happen is to look at the routing
table to determine (or now the ND cache) if the node is on the link.  If
it is the ::.... address does not have to be tunneled, thus IPv6 code is
executed on both nodes to complete the communications.

I also don't think we can require such and affect because though a node
does have both IPv6-Only and IPv4-Compatible a user may wish to use this
fact in variant ways as part of their transition and migration strategy
to IPv6 we cannot perceive.  So having a rule like that IMHO is not a
good idea.  In fact having any migration strategy for transition is not
a good idea IMHO.  

But there is a gottcha here.  IPv4-compatible addresses are not part of
ND as best I can tell and I am not sure other than manual configuration
how any local link can be determined.  So now I see another question
from your question and one I at least need to go look at.

thanks
/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 07:11:25 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07946; Mon, 14 Aug 95 07:11:25 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07940; Mon, 14 Aug 95 07:11:12 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29927; Mon, 14 Aug 1995 07:00:12 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id HAA09881; Mon, 14 Aug 1995 07:00:08 -0700
Subject: (IPng 519) v4-compat and ND (was Re: IPv6 resolver questions)
To: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Date: Mon, 14 Aug 1995 10:00:13 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: Dan McDonald <danmcd@sundance.itd.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508141500.aa00865@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In note #518, Jim Bound says:

> But there is a gottcha here.  IPv4-compatible addresses are not part of
> ND as best I can tell and I am not sure other than manual configuration
> how any local link can be determined.  So now I see another question
> from your question and one I at least need to go look at.

Hmmm, the only "problem" with IPv4-compatible addresses, from what I've
seen, is that you have to manually configure the interface.

For example, a init file we use sometimes contains the following two lines:

---
ifconfig ef0 inet6 ::<v4 address> netmask \
	ffff:ffff:ffff:ffff:ffff:ffff:<your v4 netmask>

route add -inet6 -tunnel transdefault <default v4 router address>
---

(Yes, we use routing table abuse, not a tunnelling interface.)

The routing table will then have an on-link route for my v4-compatible
addresses, much like v4 has for its on-link addresses.  (And respectively,
ARP or ND get invoked when hosts are cloned off that interface route.)
Off-link v4 addresses go through a tunnel, as the routing entry indicates.

Since v4-compatible addresses are based on the v4 infrastructure, we can
make similar v4-style assumptions about configuration.  If we had DHCP (or
DHCPv6), we could generate similar commands to the two I illustrate above.

If I didn't understand your paragraph, Jim, I apologize, and I'll clam up.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 07:13:03 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07962; Mon, 14 Aug 95 07:13:03 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA07956; Mon, 14 Aug 95 07:12:55 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00039; Mon, 14 Aug 1995 07:01:56 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id HAA10186; Mon, 14 Aug 1995 07:01:56 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA23162; Mon, 14 Aug 1995 06:54:21 -0700
Received: by xirtlu.zk3.dec.com; id AA26514; Mon, 14 Aug 1995 09:54:16 -0400
Message-Id: <9508141354.AA26514@xirtlu.zk3.dec.com>
To: Richard Stevens <rstevens@noao.edu>, ipng@sunroof.Eng.Sun.COM
Subject: (IPng 520) Re: IPv6 resolver questions 
In-Reply-To: Your message of "Mon, 14 Aug 95 09:07:38 EDT."
             <9508141307.AA24973@xirtlu.zk3.dec.com> 
Date: Mon, 14 Aug 95 09:54:10 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>to IPv6 we cannot perceive.  So having a rule like that IMHO is not a
>good idea.  In fact having any migration strategy for transition is not
>a good idea IMHO.  

Mean't that having an IETF standard with an exact migration strategy to
IPv6 that end-users MUST do is not a good idea.

thanks
/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 07:59:43 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08043; Mon, 14 Aug 95 07:59:43 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08037; Mon, 14 Aug 95 07:59:35 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03262; Mon, 14 Aug 1995 07:48:34 -0700
Received: from mail1.digital.com by venus.Sun.COM (Sun.COM)
	id HAA00950; Mon, 14 Aug 1995 07:48:34 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA20786; Mon, 14 Aug 1995 07:32:17 -0700
Received: by xirtlu.zk3.dec.com; id AA28108; Mon, 14 Aug 1995 10:32:11 -0400
Message-Id: <9508141432.AA28108@xirtlu.zk3.dec.com>
To: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Subject: (IPng 521) Re:  v4-compat and ND (was Re: IPv6 resolver questions) 
In-Reply-To: Your message of "Mon, 14 Aug 95 10:00:13 CDT."
             <9508141500.aa00865@cs.nrl.navy.mil> 
Date: Mon, 14 Aug 95 10:32:05 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>In note #518, Jim Bound says:

>> But there is a gottcha here.  IPv4-compatible addresses are not part of
>> ND as best I can tell and I am not sure other than manual configuration
>> how any local link can be determined.  So now I see another question
>> from your question and one I at least need to go look at.

>Hmmm, the only "problem" with IPv4-compatible addresses, from what I've
>seen, is that you have to manually configure the interface.

Well it could be done automatically for automatic tunnels as part of
rc.config or /etc/rc.local.

>For example, a init file we use sometimes contains the following two lines:
>
>---
>ifconfig ef0 inet6 ::<v4 address> netmask \
>	ffff:ffff:ffff:ffff:ffff:ffff:<your v4 netmask>

Ours is ip6_config (then same as yours except we create tunnel
interface tna0 which you can see if you telnet.v6 into
sipper.pa-xx.dec.com from our netstat.v6 -rn, aA, and i paramters).

For autotunnel you can have 0000:0000 for the netmask and for manual
tunnel then you need to do as you have it.

Our transport is all 16 octet and now v6 so no dual stack at the
transport.  Right now if its ::.... we just tunnel but once we can test
with v6 routers we will change this to make that determination if v4
router or v6 router OR if the user wants to tunnel anyway if the router
supports v6 and v4.  Users choice to tunnel based on how they want to
transition.

>route add -inet6 -tunnel transdefault <default v4 router address>

yep. we make our unix do this via route file too if you want.

>(Yes, we use routing table abuse, not a tunnelling interface.)

OK.  Tunnels VIFs work better because you can actually create the IPv4
header at the VIF, and on incoming packets too.

>The routing table will then have an on-link route for my v4-compatible
>addresses, much like v4 has for its on-link addresses.  (And respectively,
>ARP or ND get invoked when hosts are cloned off that interface route.)
>Off-link v4 addresses go through a tunnel, as the routing entry indicates.

This is a good idea.  Be nice to have preference for 2 or more v4
routers that exist via v6 semantics.

>Since v4-compatible addresses are based on the v4 infrastructure, we can
>make similar v4-style assumptions about configuration.  If we had DHCP (or
>DHCPv6), we could generate similar commands to the two I illustrate above.

We treat them as part of v6 infrastructure and they get their own
interface on ifnet, so they are manageable from IPv6 environment.
Because our v6 transport now handles v4 or v6 (running for over 6 months
now) the tna0 ifnet is accessible at the transport as required.

>If I didn't understand your paragraph, Jim, I apologize, and I'll clam up.

We are in synch.  

In DHCPv4 its possible to hand out ::... addresses.  In DHCPv6 this is
an issue that needs to be addressed and in Addr Conf.   The issue is the
prefix as it always has been.  

/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 09:31:10 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08150; Mon, 14 Aug 95 09:31:10 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08144; Mon, 14 Aug 95 09:30:58 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13488; Mon, 14 Aug 1995 09:19:58 -0700
Received: from IETF.nri.reston.VA.US by venus.Sun.COM (Sun.COM)
	id JAA04425; Mon, 14 Aug 1995 09:19:57 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13120;
          14 Aug 95 11:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;@venus
Cc: ipng@sunroof.Eng.Sun.COM
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: (IPng 522) I-D ACTION:draft-ietf-ipngwg-ethernet-ntwrks-00.txt
Date: Mon, 14 Aug 95 11:24:21 -0400
Message-Id:  <9508141124.aa13120@IETF.CNRI.Reston.VA.US>
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     : A Method for the Transmission of IPv6 Packets over 
                   Ethernet Networks                                       
       Author(s) : M. Crawford
       Filename  : draft-ietf-ipngwg-ethernet-ntwrks-00.txt
       Pages     : 4
       Date      : 08/11/1995

This memo specifies the frame format for transmission of IPv6 [IPV6] 
packets and the method of forming IPv6 link-local addresses on Ethernet 
networks.  It also specifies the content of the Ethernet networks.  It also
specifies the content of the Source/Target Link-layer Address option used 
the the Router Solicitation, Router Advertisement, Neighbor Solicitation, 
and Neighbor Advertisement messages described in [DISC], when those 
messages are transmitted on an Ethernet.                                   

Internet-Drafts are 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-ethernet-ntwrks-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-00.txt".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

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@ds.internic.net"

Content-Type: text/plain
Content-ID: <19950811114210.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ethernet-ntwrks-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipngwg-ethernet-ntwrks-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19950811114210.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 09:35:55 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08166; Mon, 14 Aug 95 09:35:55 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08160; Mon, 14 Aug 95 09:35:46 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14214; Mon, 14 Aug 1995 09:24:45 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id JAA05047; Mon, 14 Aug 1995 09:24:34 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA29384; Mon, 14 Aug 1995 09:19:14 -0700
Received: by xirtlu.zk3.dec.com; id AA02603; Mon, 14 Aug 1995 12:19:10 -0400
Message-Id: <9508141619.AA02603@xirtlu.zk3.dec.com>
To: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Subject: (IPng 523) TCP/IP EXPO IPv6 Interoperability Testing Data and Misc     
Date: Mon, 14 Aug 95 12:19:04 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Sending this to ipng as fyi. All discussions will take place on
ipv6imp@munnari.oz.au.  To join that list send mail to
ipv6imp-request@munnari.oz.au.

/jim


--------------------------------

Return-Path: bound
Message-Id: <9508141602.AA02281@xirtlu.zk3.dec.com>
To: ipv6imp@munnari.oz.au
Cc: bound@zk3.dec.com
Subject: TCP/IP EXPO IPv6 Testing
Date: Mon, 14 Aug 95 12:02:38 -0400
From: bound
X-Mts: smtp

We tested telnet.v6, ping.v6, and ftp.v6 at TCP/IP EXPO Aug 8-10, 1995
last week.  

The implementations were SICS, Mentat, Mitre, INRIA, HP, and Digital.
Jack Mccann and I from Digital were in the booth at TCP/IP EXPO and
worked with Mentat and HP on the phone to get things organized.  Special
thanks to Mark Hasson and Tim Hartrick from Mentat who even worked late
into the evenings (after the show closed) with us to get this figured out 
and worked to debug problems we encountered. Also thanks to Bill Medlin at 
HP for his help too.  Mark and Bill came down to the show for one day to
so that was helpful too.  We also showed the IPv6 parts to Bob Hinden and
Peter Grehan at Ipsilon so some of our local IETF IPv6 bretheren were
around too.

We were only able to test tunnels over the Internet (obviously as there
are no v6 routers).  Unfortuneately Digital was the only one on the show
floor so all we could test was with other nodes on the Internet via
tunnelling.

telnet.v6 worked fine on all implementations.   

ftp.v6 seemed to have a problem in the Digital implementation as we do
not support the LPRT feature or it could be RFC 1639 (foobar for ftp).
But we were able to transfer files but then the connection would break.
See note attached to this mail from David Talleri at Mitre who captured
the error for us.  Need to go look at ftp RFC this week and see if this
is required.   I was hoping and still hope we can just test ftp with
the ports defined to connect 1-to-1.  Not sure 3rd party ftp should be
carried over to IPv6?  I really don't want to put cycles into ftp
application until later.

ping.v6 worked for all implementations except Digital.  Digital can ping.v6
their nodes on the Internet but can't seem to do so with other nodes. We
tried to debug this and found we did have icmpv6 checksum errors per our
netstat.v6 -s utility, but looking at the checksum routine it appears to
be correct at our end.  Though our transport checksum is working fine, but 
is different from the one used in icmpv6 (prototypes for performance
thats why) so this was a good test.  It appears to be a Digital
implementation bug, but we need to make sure.  This prompted the note to ipng 
from Mark Hasson that we need to have one pseudo header checksum in one spec 
not in both IPv6 base spec and ICMPv6 spec.  Lets pick one folks.

We were able to show folks at the show autoconfigured addresses via
ip6_config -a [your ethernet interface] and the ND cache get updated
from a ping.v6 [we have put that in the BSD 4.4. radix tree now]. We
used tcpdump, netstat.v6, and arp.v6 to show real IPv6 functionality on
the show connection.  We have implemented the API spec (sockets and DNS),
and address library conversion routines so we were able to show nice
compressed v6 addr displays.  Many commented that it was nice to see
an /etc/hosts with real IPv6 addresses. At the show we were not
comfortable putting AAAA records on the show server as we would have had
to put the IPv6 code changes on the show NS server.

We showed the tcpdump of tunnled packets to our colleagues via a Motif
GUI called IRIS developed by one of our PC engineers and ported to our UNIX
code base to show IPv6 labels.  So attendees could see the actual
packets that used protocol ID 41.  We showed them on the GUI first the
IPv4 header and contents and then the IPv6 encapsulated packet so it was
not smoke and mirrors.   We also showed them the all-nodes multicast in
ND to discover our nodes on the shownet.

One night Jack and I did see something strange.  It was about 1:30 a.m.
and we were staging our equipment (yes we like risk and thank whoever
that tar really works with tapes).  We could not get anything back from
telnet.v6.  So we jumped on sipper from a back door and verified we were
sending 1480 size packets.  A router would pick that up and then
fragment to us with an ID.  We would get that fragment then the router
would time-out (we think) and send another fragment but changed the ID.
Well this don't work as we kept throwing the packet away looking for
like IDs.  We think this was a bogus router but need to go look at our
code and make sure we did nothing to screw up IPv4 frag/reassembly which
we have left in tact as far as we know (we did not touch it yet
directly).  We got around this by dbxing sipper VIF tunnel interface to
576 octets and all worked fine after that as no packets got fragmented
enroute to our node on the show floor.

I did extensive press interview with PC Week on IPv6 for Digital marketing,
and what we were doing at the show.  This was nice and I got all the 
implementation names in the interview and they will also contact Mentat and
HP was my understanding.  We did a demo for them and showed them IPv6 can
really work.  One question I answered which took them by surprise was that
we need to be deployed by 1998 as I personally believe from my intelligence
and customer contacts we will begin to see customers run out of address
space by 1998 in some cases.  The key is that CIDR or any other scheme does 
not prevent the exhaustion of IPv4 address space (see Christian Huitema's new
book Routing In the Internet [a really good book I might add] chapter on
CIDR which I referenced to the reporter).  Also had nice interview with
PC LABs and the reporter wanted to cover the positive reasons a customer
would want to move to IPv6, instead of doing it because of the pain of
addresses being exhausted and they have to move to IPv6.  This was a
chance to list the new things we can do in IPv6 that for the most part
cannot be done in IPv4.  Digital Review came by and I talked to them and 
showed them IPv6 running too.  Generally the Press now knows IPv6 is real 
and implementations though in prototype stage (not product) are underway. 
When asked what was the most important part to implement in IPv6 I answered,
all of it because until I and think others see it running and across multiple
interoperable implementations its all theory and architecture hopes.  But, 
my opinion is the specs for the most part look pretty good, but every 
sentence in every spec needs to be tested, because we are not just talking 
about an update to an existing spec or one new feature, but a new 
implementation of of a protocol to support IPv6 with many changes to the 
complete stack.  Pointed out at this time we have no routers to test
IPv6 but that Bay Networks was working on an IPv6 prototype so we could
test at some point in the future and we will build a prototype router on
Digital UNIX for IPv6 for testing also sometime this fall.  We don't
really need IPv6 routers to begin the transition to IPv6 but we do need
them to route IPv6 only packets.  Then did discussion on transition
scenarios that can take place.

We also had the IPng WWW page on our screens for people to see too.

I did presentation of our IPv6 implementation experience and will make
those slides available to Bob Hinden to put on our IPng WWW page.  So
anyone can get them if they want.

We learned alot about the existing implementations and had some good
idea discussions around Addr Conf, RSVP, APIs, ND, and DHCPv6 as we ran
the code and tested the basic philosophy and architecture principles
that all those specs will be built upon over the next year.  But most of
all this was fun, and very cool to be able to work with others to build
and test IPv6 as a team of vendors and researchers to see if this thing
we have defined and architected called IPv6 really works. 

/jim

----------------------------------------------
Return-Path: dtalleri@gateway.mitre.org
Received: from decvax.zk3.dec.com by alpha.zk3.dec.com; (5.65v3.0/1.1.8.2/20May95-1022AM)
	id AA07760; Wed, 9 Aug 1995 13:07:36 -0400
Received: from mwunix.mitre.org by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
	id AA08694; Wed, 9 Aug 1995 13:07:21 -0400
Return-Path: dtalleri@gateway.mitre.org
Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id NAA14746 for <bound@zk3.dec.com>; Wed, 9 Aug 1995 13:04:45 -0400
Received: from pagoda.mitre.org by gateway.mitre.org (4.1/SMI-4.1)
	id AA25207; Wed, 9 Aug 95 13:04:43 EDT
Date: Wed, 9 Aug 95 13:04:43 EDT
From: dtalleri@gateway.mitre.org (David Tallerico)
Message-Id: <9508091704.AA25207@gateway.mitre.org>
To: bound@zk3.dec.com
Subject: Re: IPv6 tunnel


Jim,

I finally wised up and tried telnet6 to sipper, and that worked
fine.  ping6 and ftp6 don't work, however.  With ftp, I get the
following error (this is using INRIA's ftp client):

     ftp> ls
     500 'LPRT 6,16,0,0,0,0,0,0,0,0,0,0,0,0,192,188,104,99,2,4,1': command not understood.
     150 Opening ASCII mode data connection for /bin/ls.
     total 9
     -rwxr-xr-x   1 500      26          1499 Feb  3  1995 .cshrc
     -rwxr-xr-x   1 500      26          1639 Feb  3  1995 .login
     -rwxr-xr-x   1 500      26          1580 Feb  3  1995 .profile
     d--x--x--x   2 0        26           512 Mar 25  1993 bin
     d--x--x--x   2 0        26           512 Mar 25  1993 etc
     drwxr-xr-x   2 0        26           512 Mar 25  1993 pub


If you do try tunneling to ::192.188.104.99, and succeed (ping6 only,
still, but I'm hoping to change that), could you please run 
traceroute and mail me the reported path. 

Thanks,

- -David

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 11:41:46 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08319; Mon, 14 Aug 95 11:41:46 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08313; Mon, 14 Aug 95 11:41:38 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id LAA01621; Mon, 14 Aug 1995 11:30:37 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id LAA25961; Mon, 14 Aug 1995 11:30:14 -0700
Date: Mon, 14 Aug 1995 11:30:14 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508141830.LAA25961@bobo.Eng.Sun.COM>
To: bound@zk3.dec.com
Subject: (IPng 524) Re: On source address determination
Cc: ipng@sunroof
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> >> I can see a basic set of rules where:
> >> 
> >> 	1. If link-local dest, use link-local src.
> >> 	2. If v4-compatible dest, use v4-compatible src.
> >> 	3. If site-local dest, use site-local src.
> >> 	4. Otherwise, pick "best" source on that interface.
> 
> >Those rules look reasonable as long as you handle the case when the
> >interface doesn't have a v4-compatible or site-local address.
> 
> Reasonable yes the only way to do it NO.  Don't want to see this in ND
> spec as we will never get to proposed standard.

Agreed. I am not proposing that source address selection rules be added
to the ND spec.

   Erik

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 14 18:10:05 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08665; Mon, 14 Aug 95 18:10:05 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08659; Mon, 14 Aug 95 18:09:57 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA24414; Mon, 14 Aug 1995 17:58:55 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA02213; Mon, 14 Aug 1995 17:58:32 -0700
Date: Mon, 14 Aug 1995 17:58:32 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508150058.RAA02213@bobo.Eng.Sun.COM>
To: dan@lkg.dec.com
Subject: (IPng 525) Re: ND: Receive MTU option
Cc: ipng@sunroof
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> Just a quick data point...In the CLNP implementation I work on, we deal
> with this issue by keeping a reverse path cache which includes a test of
> the datalink header to see if the source of a given packet is On-Ring.
> If so, the full FDDI blocksize can be utilized to exchange data with that
> particular destination.  Otherwise the lower Ethernet blocksize must be used.

Does this imply that the receiving CLNP has to look at the datalink
header for every received packet?  If so, do you have
any feel for the performance degration caused by inspecting all the 
received dl headers?

> This seemed more reliable than trusting folks to never configure the
> dreaded dumbbell LAN...it also doesn't require an MTU option.

It would be nice to have such a mechanism as a safety against 
misconfiguration.  Howver, I'm concerned about its performance impact.

A possible and simple solution for IPv6 is to assume that bridges
between e.g. FDDI and Ethernet will at some point be modified
to return ICMP packet too big errors when IPv6 packets don't fit.
That way Path MTU discovery will work for (unicast and multicast)
across the bridge.

In order to deal with bridges that have yet not be modified administrators
can use the MTU option to limit the (IPv6) MTU on the FDDI segments to
1500 bytes.

   Erik
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 07:25:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08936; Tue, 15 Aug 95 07:25:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08930; Tue, 15 Aug 95 07:25:27 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28279; Tue, 15 Aug 1995 07:14:23 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id HAA24869; Tue, 15 Aug 1995 07:14:19 -0700
Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA01834; Tue, 15 Aug 1995 07:05:55 -0700
Received:  from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
	id AA04393; Tue, 15 Aug 1995 10:05:53 -0400
Received: by netrix.lkg.dec.com; (5.65/1.1.8.2/28May95-0415PM)
	id AA21720; Tue, 15 Aug 1995 10:05:48 -0400
Date: Tue, 15 Aug 1995 10:05:48 -0400
From: Dan Harrington <dan@lkg.dec.com>
Message-Id: <9508151405.AA21720@netrix.lkg.dec.com>
To: dan@lkg.dec.com, nordmark@jurassic-248.Eng.Sun.COM
Subject: (IPng 526) Re: ND: Receive MTU option
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Hi Erik,

> Does this imply that the receiving CLNP has to look at the datalink
> header for every received packet?  If so, do you have
> any feel for the performance degration caused by inspecting all the 
> received dl headers?
> 
>> This seemed more reliable than trusting folks to never configure the
>> dreaded dumbbell LAN...it also doesn't require an MTU option.
> 
> It would be nice to have such a mechanism as a safety against 
> misconfiguration.  Howver, I'm concerned about its performance impact.

I oversimplified the description a bit, but yes, for FDDI circuits
the datalink layer will test the frame and set a flag, which is then
passed up to the CLNP layer and tested.  So this is only done for
FDDI interfaces, and the tradeoff is the potential for higher throughput
to On Ring neighbors.  I don't have any before/after numbers handy,
but I could either dig up some test results done at the time, or
rerun the tests.  Let me know if you're interested.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 09:53:08 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08995; Tue, 15 Aug 95 09:53:08 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA08976; Tue, 15 Aug 95 09:45:23 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13064; Tue, 15 Aug 1995 09:34:20 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id JAA21859; Tue, 15 Aug 1995 09:34:18 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HU3MUYDEEO000WWG@FNAL.FNAL.GOV>; Tue, 15 Aug 1995 11:34:04 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA09874; Tue, 15 Aug 95 11:33:22 CDT
Date: Tue, 15 Aug 1995 11:33:21 -0500
From: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Subject: (IPng 527) Re: ND: Receive MTU option
In-Reply-To: Your message of Mon,
 14 Aug 95 17:58:32 PDT. <199508150058.RAA02213@bobo.Eng.Sun.COM>
To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark)
Cc: dan@lkg.dec.com, ipng@sunroof.Eng.Sun.COM
Message-Id: <9508151633.AA09874@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

    A possible and simple solution for IPv6 is to assume that bridges
    between e.g. FDDI and Ethernet will at some point be modified
    to return ICMP packet too big errors when IPv6 packets don't fit.
    That way Path MTU discovery will work for (unicast and multicast)
    across the bridge.

This is exactly what I hope to avoid, because so many bridge vendors
have utterly failed to do this (or to do this correctly) for IPv4.
After I get the IPv6-over-fddi draft in the mail (later today, I
hope), I will propose a mechanism that needs no smarts in the bridge
(other than the usual ETHER<-->SNAP translation) and no hair in the
stack of an ethernet host, and which works even in the "dumbell"
FDDI-[bridge]-ETHER-[bridge]-FDDI case.  It does involve having the
router(s) on such a subnet sending multiple MTU options in their RA
messages if all the routers are on the same medium type.
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 11:31:38 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09193; Tue, 15 Aug 95 11:31:38 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09187; Tue, 15 Aug 95 11:31:25 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29515; Tue, 15 Aug 1995 11:20:20 -0700
Received: from bodhi.nrl.navy.mil by venus.Sun.COM (Sun.COM)
	id LAA27203; Tue, 15 Aug 1995 11:20:19 -0700
From: Ran Atkinson <rja@bodhi.nrl.navy.mil>
Message-Id: <9508151416.ZM26462@bodhi.nrl.navy.mil>
Date: Tue, 15 Aug 1995 14:16:01 -0400
Reply-To: rja@cs.nrl.navy.mil
X-Mailer: Z-Mail (3.2.1 10apr95)
To: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 528) IP Auth Header code fragment available
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


IPng WG folks,

  There recently has been some discussion of implementation complexity
of the IP Authentication Header on the IPsec WG list.

  To help reassure those who thought that it might be too hard to
implement and to provide some concrete basis for discussions, we've
released an early code fragment from our AH code to our ftp site
	ftp://ftp.nrl.navy.mil/pub/security/ipsec

  This fragment is copyrighted but is freely distributable under the
license terms included in the source file.  The whole file will be
included in our "alpha" release of IPv6 software under the same
license terms when the "alpha" goes out.  The fragment covers both
IPv6 and IPv4 processing.  I mention it here in addition to the IPsec
mailing list because I thought it might be of interest here.

  Discussion followups probably belong on the ipsec list rather than
ipng, please use your own judgement.

Ran
rja@cs.nrl.navy.mil

employed by, but not speaking officially for the
	US Naval Research Laboratory

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 13:51:13 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09306; Tue, 15 Aug 95 13:51:13 PDT
Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09300; Tue, 15 Aug 95 13:51:04 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id NAA23335; Tue, 15 Aug 1995 13:40:03 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id NAA05041; Tue, 15 Aug 1995 13:39:39 -0700
Date: Tue, 15 Aug 1995 13:39:39 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508152039.NAA05041@bobo.Eng.Sun.COM>
To: crawdad@FNAL.FNAL.GOV
Subject: (IPng 529) Re: ND: Receive MTU option
Cc: ipng@sunroof
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> This is exactly what I hope to avoid, because so many bridge vendors
> have utterly failed to do this (or to do this correctly) for IPv4.
> After I get the IPv6-over-fddi draft in the mail (later today, I
> hope), I will propose a mechanism that needs no smarts in the bridge
> (other than the usual ETHER<-->SNAP translation) and no hair in the
> stack of an ethernet host, and which works even in the "dumbell"
> FDDI-[bridge]-ETHER-[bridge]-FDDI case.  It does involve having the
> router(s) on such a subnet sending multiple MTU options in their RA
> messages if all the routers are on the same medium type.

It seems like your are contemplating some changes to Neighbor Discovery
to accomplish this.  According to the ND spec that hosts will only use
the last MTU option they have received so there would be no utility
in having the routers sending out multiple such options. Care to specify
what changes you're propsing - or should I wait for the draft?

Also, will your proposal handle FDDI<->Ether<->FDDI bridging configurations?

   Erik
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 15:14:57 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09380; Tue, 15 Aug 95 15:14:57 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09374; Tue, 15 Aug 95 15:14:49 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA01990; Tue, 15 Aug 1995 15:03:47 -0700
Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM)
	id PAA06435; Tue, 15 Aug 1995 15:03:43 -0700
Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com
	with SMTP id SAA10091 for <ipng@sunroof.Eng.Sun.COM>; Tue, 15 Aug 1995 18:03:27 -0400
Message-Id: <199508152203.SAA10091@dylan.mindspring.com>
X-Sender: sthomas@mindspring.com
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Aug 1995 17:49:07 -0400
To: ipng@sunroof.Eng.Sun.COM
From: Stephen Thomas <sthomas@mindspring.com>
Subject: (IPng 530) Re: ND: Receive MTU option
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


FWIW:

I'm not neccessarily recommending this approach, but it might spark
some fruitful discussion. Have routers pad their advertisements up
to the maximum length (as spec'd by the advertised MTU).

In case anyone wants to pursue this further, here's a quick strawman:

1) All hosts assume that the MTU of all local links is 576 unless 
   (a) they are explicitly configured otherwise, or (b) they receive
   a RA with a different advertised MTU.

2) Routers generate RAs both with and without local MTU options.
   The RAs without MTU options are not padded, but those with an
   MTU option are always padded to the length specified in the
   MTU option. Routers are allowed to send RAs with different
   MTU options. The final 32 bits in the MTU option (currently
   reserved) specify a holding time for the MTU value.

3) Hosts keep an MTU value in their neighbor cache. This value defaults
   to 576 and increases to the highest MTU option received in a
   RA from that neighbor, subject to the holding time expiration.

It probably needs a few tweaks here and there, but, if you can stand the
extra bandwidth that all that padding chews up, I think it gets the
job done. (BTW: The idea isn't mine originally, it comes from how IS-IS
handles its hello PDUs.)

--Stephen

________________________
Stephen A. Thomas
4397 Windsor Oaks Circle
Marietta, GA  30066-2387
E-mail: s.thomas@acm.org

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 16:03:03 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09421; Tue, 15 Aug 95 16:03:03 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09415; Tue, 15 Aug 95 16:02:55 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AB08437; Tue, 15 Aug 1995 15:51:53 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id PAA15418; Tue, 15 Aug 1995 15:51:51 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HU40283SMO0013QD@FNAL.FNAL.GOV>; Tue, 15 Aug 1995 17:51:45 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA11707; Tue, 15 Aug 95 17:51:05 CDT
Date: Tue, 15 Aug 1995 17:51:05 -0500
From: crawdad@munin.fnal.gov (Matt Crawford)
Subject: (IPng 531) Re: ND: Receive MTU option
In-Reply-To: Your message of Tue,
 15 Aug 95 17:49:07 EDT. <199508152203.SAA10091@dylan.mindspring.com>
To: Stephen Thomas <sthomas@mindspring.com>
Cc: ipng@sunroof.Eng.Sun.COM
Message-Id: <9508152251.AA11707@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Stephen,

Your strawman seems not to solve the following problem (which isn't
even the hardest problem):

An FDDI and an Ethernet are bridged together by a bridge which knows
nothing about IPv6, let alone ICMPv6.

On FDDI are host A and router R.

On Ethernet is host B.

Host A will know and use an MTU of 4352 octets -- either configured
or learned from R -- and will not always communicate successfully
with host B.


I don't see any gain *in this scenario* for the padding in the RA.
However, I see that it does get you something in the generally harder
dumbell case:

	FDDI1 --[bridge]-- ETHER --[bridge]-- FDDI2

Your padding keeps hosts on FDDI2 from sending large packets to
*routers* on FDDI1.
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 15 21:11:22 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09577; Tue, 15 Aug 95 21:11:22 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09571; Tue, 15 Aug 95 21:11:14 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA07927; Tue, 15 Aug 1995 21:00:10 -0700
Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM)
	id VAA24442; Tue, 15 Aug 1995 21:00:04 -0700
Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com
	with SMTP id XAA16121 for <ipng@sunroof.Eng.Sun.COM>; Tue, 15 Aug 1995 23:59:57 -0400
Message-Id: <199508160359.XAA16121@dylan.mindspring.com>
X-Sender: sthomas@mindspring.com
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 15 Aug 1995 23:45:09 -0400
To: ipng@sunroof.Eng.Sun.COM
From: Stephen Thomas <sthomas@mindspring.com>
Subject: (IPng 532) Padded ND packets (was Re: ND: Receive MTU option)
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

>From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark)

>Clarification on your strawman:
>
>Wouldn't the MTU option plus padding be needed on all ND packets
>i.e. NA and NS as well? Without this a host would never learn 
>an MTU larger than the default when talking to other hosts.

As it stands, yes. Like I said when I started this thread, I'm not
real fond of the approach as I envision it. I threw it out to see
if a more enlightened soul could improve upon it.

I'm not worried so much about the extra bandwidth the padding
takes up (but I'd rather it be absent just the same). The real
mess is having RAs and NAs (we could probably get by without padding
NSs) with all these different MTU options.

If I'm building a system, what MTUs do I advertise? Worst case might
be a 16 Mbit/s Token Ring.

  1) None (same as 576) to handle worst case (remote bridges?)
  2) 1500 in case there's an Ethernet floating around somewhere
  3) 2000+/- in case a 4 Mbit/s Token Ring's in the mix
  4) 4000+/- to handle FDDI rings
  5) 8000+/- for everyone on my own ring

When does it end? (Heck, we could throw in a few 100VG-AnyLAN networks
and really get wild.)

If anyone has lightbulbs going off over their head, please jump in.


--Stephen


________________________
Stephen A. Thomas
4397 Windsor Oaks Circle
Marietta, GA  30066-2387
E-mail: s.thomas@acm.org

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 16 10:45:17 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09817; Wed, 16 Aug 95 10:45:17 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09811; Wed, 16 Aug 95 10:45:09 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA27279; Wed, 16 Aug 1995 10:34:05 -0700
Received: from BBN.COM by mercury.Sun.COM (Sun.COM)
	id KAA24515; Wed, 16 Aug 1995 10:34:00 -0700
Received: from aland.bbn.com by BBN.COM id aa13833; 16 Aug 95 13:30 EDT
Received: by aland.bbn.com (8.6.12/3.1.090690-BBN)
	id KAA04308; Wed, 16 Aug 1995 10:30:31 -0700
Message-Id: <199508161730.KAA04308@aland.bbn.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 533) question about IPv6 and MAC IDs
Reply-To: Craig Partridge <craig@aland.bbn.com>
From: Craig Partridge <craig@aland.bbn.com>
Date: Wed, 16 Aug 95 10:30:30 -0700
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Hi:
    
    I remember a discussion on this list a while back about whether one
should get new MAC identifiers (e.g., new LLC/SNAP ids) for IPv6.

    What was the resolution?  (I trying to advise someone on how to make
a router run fast using IPv6 and this issue popped out as a minor detail).

Thanks!

Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 16 12:58:18 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09960; Wed, 16 Aug 95 12:58:18 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA09954; Wed, 16 Aug 95 12:58:09 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16067; Wed, 16 Aug 1995 12:47:06 -0700
Received: from alpha.xerox.com by venus.Sun.COM (Sun.COM)
	id MAA15690; Wed, 16 Aug 1995 12:47:03 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15540(6)>; Wed, 16 Aug 1995 12:45:29 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 16 Aug 1995 12:45:22 -0700
To: Craig Partridge <craig@aland.bbn.com>
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
Subject: (IPng 534) Re:  question about IPv6 and MAC IDs 
In-Reply-To: craig's message of Wed, 16 Aug 95 10:30:30 -0800.
             <199508161730.KAA04308@aland.bbn.com> 
Date: Wed, 16 Aug 1995 12:45:17 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug16.124522pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

>     I remember a discussion on this list a while back about whether one
> should get new MAC identifiers (e.g., new LLC/SNAP ids) for IPv6.
> 
>     What was the resolution?  (I trying to advise someone on how to make
> a router run fast using IPv6 and this issue popped out as a minor detail).

Assuming you are referring to the ethertype (or functional equivalent on
media other than Ethernet), we did decide to use a distinct value for IPv6.
See draft-ietf-ipngwg-ethernet-ntwrks-00.txt for the Ethernet example.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 17 08:21:08 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10369; Thu, 17 Aug 95 08:21:08 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10363; Thu, 17 Aug 95 08:20:54 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA07066; Thu, 17 Aug 1995 08:09:46 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id IAA09225; Thu, 17 Aug 1995 08:09:44 -0700
Subject: (IPng 535) Jumbograms and UDP
To: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Date: Thu, 17 Aug 1995 11:09:55 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: Dan McDonald <danmcd@sundance.itd.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508171609.aa11644@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

If this has been dealt with already, I apologize.  (I don't have
jumbogram-capable hardware, so jumbograms aren't at the forefront of my
mind.)

An interesting question was posed on end2end-interest a few days ago,
regarding which length a UDP implementation should use, the UDP length or
the IP length.  That issue was resolved, the resolution being use the UDP
length (which may be shorter than the IP length).

This brings up another question, specific to IPv6, and hence, this list.

	What do I put in the UDP length field if the datagram is an IPv6
	jumbogram?

The IPv6 spec has no indication on what to do.  I personally think that the
UDP length should be 0, and UDP code should realize that it is dealing with
a jumbogram when checking for the validity of a length field in the UDP
header.  (Normally a 0 UDP length is an error, but Dave Borman pointed out a
bug in 4.4 BSD where it doesn't quite handle this.  See the end2end-interest
archives.)

As we don't have jumbogram-delivering hardware, I cannot personally test how
good my solution (put 0 in the UDP header for jumbograms and let IP send
jumbogram hints to UDP) is.

{\begin MST3K}

"So sirs, what do you think?"

{\end MST3K}

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 17 08:37:06 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10384; Thu, 17 Aug 95 08:37:06 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10378; Thu, 17 Aug 95 08:36:53 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA08843; Thu, 17 Aug 1995 08:25:44 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id IAA12356; Thu, 17 Aug 1995 08:25:42 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id LAA00557; Thu, 17 Aug 1995 11:25:52 -0400 (EDT)
Date: Thu, 17 Aug 1995 11:25:52 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508171525.LAA00557@newdev.harvard.edu>
To: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 536) Re:  Jumbograms and UDP
Cc: danmcd@sundance.itd.nrl.navy.mil
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> I personally think that the UDP length should be 0

if so would the application be able to retrieve the hop-by-hop option?
seems like a layer violation :-)

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 17 09:36:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10443; Thu, 17 Aug 95 09:36:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10437; Thu, 17 Aug 95 09:36:24 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16130; Thu, 17 Aug 1995 09:25:16 -0700
Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM)
	id JAA24650; Thu, 17 Aug 1995 09:25:04 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05758;
          17 Aug 95 11:36 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;@mercury
Cc: ipng@sunroof.Eng.Sun.COM
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: (IPng 537) I-D ACTION:draft-ietf-ipngwg-fddi-ntwrks-00.txt
Date: Thu, 17 Aug 95 11:36:45 -0400
Message-Id:  <9508171136.aa05758@IETF.CNRI.Reston.VA.US>
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     : A Method for the Transmission of IPv6 Packets 
                   over FDDI Networks                                                
       Author(s) : M. Crawford
       Filename  : draft-ietf-ipngwg-fddi-ntwrks-00.txt
       Pages     : 5
       Date      : 08/16/1995

This memo specifies the frame format for transmission of IPv6 [IPV6] 
packets and the method of forming IPv6 link-local addresses on FDDI 
networks.  It also specifies the content of the Source/Target Link-layer 
Address option used the the Router Solicitation, Router Advertisement, 
Neighbor Solicitation, and Neighbor Advertisement messages described in 
[DISC], when those messages are transmitted on an FDDI network.            

Internet-Drafts are 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-fddi-ntwrks-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-00.txt".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

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@ds.internic.net"

Content-Type: text/plain
Content-ID: <19950816165827.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipngwg-fddi-ntwrks-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19950816165827.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 17 09:45:35 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10477; Thu, 17 Aug 95 09:45:35 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10471; Thu, 17 Aug 95 09:45:22 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA17542; Thu, 17 Aug 1995 09:34:13 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id JAA27004; Thu, 17 Aug 1995 09:34:10 -0700
Subject: (IPng 538) Re:  Jumbograms and UDP
To: Scott Bradner <sob@newdev.harvard.edu>
Date: Thu, 17 Aug 1995 12:34:11 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM
In-Reply-To: <199508171525.LAA00557@newdev.harvard.edu> from "Scott Bradner" at Aug 17, 95 11:25:52 am
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508171734.aa12082@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> if so would the application be able to retrieve the hop-by-hop option?
> seems like a layer violation :-)

Don't even START with me on layering.  Uggh, everything I learned with the
x-kernel is slowly eroding as I dig deeper and deeper into BSD.  (A slow,
sobbing sound is heard at this point. :-)

In all seriousness, in my implementation, the length can be obtained not
from the hop-by-hop option, but the datagram (mbuf chain, in my case)
itself.  If the length is > 64k - (whatever), then I as UDP should know
whether I have a jumbogram or not.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 17 12:35:48 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10761; Thu, 17 Aug 95 12:35:48 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA10755; Thu, 17 Aug 95 12:35:39 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12521; Thu, 17 Aug 1995 12:24:32 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id MAA08979; Thu, 17 Aug 1995 12:24:24 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA24013; Thu, 17 Aug 1995 12:08:31 -0700
Received: by xirtlu.zk3.dec.com; id AA25295; Thu, 17 Aug 1995 15:08:26 -0400
Message-Id: <9508171908.AA25295@xirtlu.zk3.dec.com>
To: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: Scott Bradner    <sob@newdev.harvard.edu>, ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 539) Re: Jumbograms and UDP 
In-Reply-To: Your message of "Thu, 17 Aug 95 12:34:11 CDT."
             <9508171734.aa12082@cs.nrl.navy.mil> 
Date: Thu, 17 Aug 95 15:08:20 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>In all seriousness, in my implementation, the length can be obtained not
>from the hop-by-hop option, but the datagram (mbuf chain, in my case)
>itself.  If the length is > 64k - (whatever), then I as UDP should know
>whether I have a jumbogram or not.

Dan is right at my end too.  Layers are an architecture commnications
vehicle. If you actually work with the IP stack especially with IPv6 
addrconf, ND, Mobile, and IPv4-IP6 Transition parts layers become void.

I checked real quick in our implementation a UDP length 0 would work.
It seems so simple its probably the right thing to do.  I checked to
when the headers are parsed and the tunneling.  As long as its always
the last part of a packet we are cool.  In the case of IPv6-in-IPv6
tunneling there may be a problem.  ALso if the IPv6 paket header-length
is zero then that tells you jumbo and you cannot determine the entire
packet length.  But I will wait on this as I think Steve is to do an
update of the spec (right) and I know there were a couple of errors and
one was I thought on jumbograms.

It will work with our transport checksums what Dan proposed too.  Need
to look at ICMP and doing it right now.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 06:20:20 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11265; Fri, 18 Aug 95 06:20:20 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11259; Fri, 18 Aug 95 06:20:10 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29443; Fri, 18 Aug 1995 06:09:05 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id GAA07560; Fri, 18 Aug 1995 06:09:04 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA14041; Fri, 18 Aug 1995 06:01:49 -0700
Received: by xirtlu.zk3.dec.com; id AA09820; Fri, 18 Aug 1995 09:01:47 -0400
Message-Id: <9508181301.AA09820@xirtlu.zk3.dec.com>
To: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 540) IPv6 Address Space and Architecture Spec              
Date: Fri, 18 Aug 95 09:01:41 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Are we going to get an IPv6 address space set up with IANA so we can
request IPv6 addresses?  Or at least a test address space.

I think we also need to move the address architecture spec to proposed
standard A.S.A.P.  and the IPv6 Protocol Spec.  Why is this not done
yet?  WG Chairs whats the hold up?  Lets get going OK.  

We need more than ever as a Working Group the chairs to have as their
first priority these specs moved to proposed standard.

Neighbor Discovery and ICMP specs?  We have outstanding questions and
and data from Stockholm, when does the WG get an updated spec?  We need
this now.  Marc Hassons note about the checksum differences in the
protocol spec and icmp needs an answer no matter how minor it appears.
Lets get going.

I am going to contact Bob Hinden off line as I may be able to run the
first root name server for IPv6-INT until it becomes an administrative
major task (which I think will take at least six months).  So we have an
IPv6 name space on the Internet.  It would use v4 protocol for access
initially.  

WG Chairs please bug the ADs or IESG to get this done or the IAB.  We need 
an IPv6 formally announced address space.  End Users also want to understand
this now to plan for 2 years from now.  Lots of us don't believe any of
the standards for IPv4 to save address space is enough we need to get to
IPv6 now and move forward.  Anything other than standards for IPv4 such
as the recent pleas and memos of please do this are fine, but most of
the industry will just say lets go to IPv6 and get it over with.
Besides no one takes the IETF seriously about Policy only the
standards and technical work.

We need to get the ball rolling on IPv6 and test each spec and make sure
its implementable and then test them on the Internet.  To some folks we
are already out of address space for IPv4.  Its getting bad now.

thanks
/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 06:44:20 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11282; Fri, 18 Aug 95 06:44:20 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11276; Fri, 18 Aug 95 06:44:12 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00821; Fri, 18 Aug 1995 06:33:06 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id GAA10643; Fri, 18 Aug 1995 06:33:07 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA15714; Fri, 18 Aug 1995 06:25:30 -0700
Received: by xirtlu.zk3.dec.com; id AA10654; Fri, 18 Aug 1995 09:25:27 -0400
Message-Id: <9508181325.AA10654@xirtlu.zk3.dec.com>
To: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 541) PC Week TCP/IP EXPO IPv6 Article fyi ................ 
Date: Fri, 18 Aug 95 09:25:21 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Forwards removed....

<head>
<title>IP Version 6 Gains from DEC Demo</title>
</head><body>
<h1>IP Version 6 Gains from DEC Demo</h1>
Source: <source>PC Week</source><br>
Date: <date>08-17-95</date><br>
<hr>
PC Week via First! : Digital Equipment Corp. at the recent TCP/IP Expo in San
 Jose, Calif., conducted the first public interoperability demonstration of the
 IP Version 6 protocol suite, a major milestone for the emerging routing
 specification.
<p>
The new routing protocols are currently wending their way to Internet
 Engineering Task Force approval, but the test made clear how far the IETF's IP
 V6 working group has to go in completing its work.
<p>
Although the DEC demonstration was able to establish an IP V6 connection between
 the San Jose convention center and an IP host in Stockholm, Sweden, the IP V6
 packet was encapsulated within an IP V4 (the current protocol) packet. That's
 because no routing vendors have yet implemented a prototype of the
 specification, according to Jim Bound, technical staff member at DEC, in Nashua,
 N.H. DEC's demonstration also included a connection to protocol supplier Mentat
 Inc., in Los Angeles.
<p>
Although there are enough prototypes implemented that would allow native IP V6
 packets to traverse a LAN, there are "only small islands of V6 implemented on
 the Internet. That's why you have to get through the Internet using
 encapsulation," said Allison Mankin, area co-director for IP Next Generation at
 the Information Sciences Institute, in Arlington, Va.
<p>
Several vendors, including FTP Software Inc., Hewlett-Packard Co., and others
 are developing their prototypes now, and Bay Networks Inc. has committed to
 developing a prototype, according to Bound, one of IP V6's authors. Cisco
 Systems Inc. is also developing a prototype, company officials said.
<p>
Those prototyes reflect work well along on a number of fronts. At least eight
 components of the suite are expected to be ready for proposed standard status by
 the IETF's Dec. 1 meeting in Dallas. Those include the basic protocol, address
 architecture, Domain Name System, Domain Name System Incremental Zone Transfer
 and Notification, an API, and neighbor discovery, according to Mankin. The
 security specification for V2 is already a Request for Comments. "We're in the
 very fine tuning stages of all of them," she said.
<p>
The completed security spec should go a long way toward relieving the support
 burden added to Internet connections, according to Bob Moskowitz, a
 technical-support specialist at Chrysler Corp. and an Internet Activities Board
 member.
<p>
Address resolution in IP V6 greatly improves on the current IP V4 functionality,
 according to Bound. Although the Dynamic Host Configuration Protocol
 specification--an add-on for IP V4 networks-- greatly eased IP address
 configuration, it falls short in supporting mobile users.
<p>
The Domain Name System component will allow the name space for the Internet to
 be dynamically updated. That will allow a mobile user to be dynamically
 configured across the Internet, Bound explained.
<p>
Paula Musich, PC Week
<p>

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 07:02:40 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11310; Fri, 18 Aug 95 07:02:40 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11304; Fri, 18 Aug 95 07:02:32 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA02012; Fri, 18 Aug 1995 06:51:18 -0700
Received: from ns.iij.ad.jp by mercury.Sun.COM (Sun.COM)
	id GAA13388; Fri, 18 Aug 1995 06:51:14 -0700
Received: from argus.iij.ad.jp (argus.iij.ad.jp [192.244.176.41]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id WAA07279; Fri, 18 Aug 1995 22:48:02 +0900
Message-Id: <199508181348.WAA07279@ns.iij.ad.jp>
To: bound@zk3.dec.com
Cc: ipng@sunroof2.Eng.Sun.COM, davidc@ns.iij.ad.jp
Subject: (IPng 542) Re:  IPv6 Address Space and Architecture Spec 
In-Reply-To: Your message of "Fri, 18 Aug 1995 09:01:41 -0400."
             <9508181301.AA09820@xirtlu.zk3.dec.com> 
Date: Fri, 18 Aug 1995 22:49:34 +0900
From: David R Conrad <davidc@iij.ad.jp>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

>Are we going to get an IPv6 address space set up with IANA so we can
>request IPv6 addresses?  Or at least a test address space.

Given the inevitable political ... discussions, why do you need the
IANA to do this?  Why not just set up "Jim's IPv6 Registry" and assign
the addresses yourself?  I mean, it's not like any IPv6 address is
"permanent" in the way v4 addresses are, right?

Regards,
-drc

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 07:19:47 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11330; Fri, 18 Aug 95 07:19:47 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11324; Fri, 18 Aug 95 07:19:39 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03326; Fri, 18 Aug 1995 07:08:33 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id HAA16245; Fri, 18 Aug 1995 07:08:33 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA17427; Fri, 18 Aug 1995 07:04:33 -0700
Received: by xirtlu.zk3.dec.com; id AA11861; Fri, 18 Aug 1995 10:04:30 -0400
Message-Id: <9508181404.AA11861@xirtlu.zk3.dec.com>
To: David R Conrad <davidc@iij.ad.jp>
Cc: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 543) Re:  IPv6 Address Space and Architecture Spec 
In-Reply-To: Your message of "Fri, 18 Aug 95 22:49:34 +0900."
             <199508181348.WAA07279@ns.iij.ad.jp> 
Date: Fri, 18 Aug 95 10:04:24 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>>Are we going to get an IPv6 address space set up with IANA so we can
>>request IPv6 addresses?  Or at least a test address space.

>Given the inevitable political ... discussions, why do you need the
>IANA to do this?  Why not just set up "Jim's IPv6 Registry" and assign
the addresses yourself?  I mean, it's not like any IPv6 address is
>"permanent" in the way v4 addresses are, right?

Several reasons.

1.  I think someone else is more qualified to set up a test address
    space such as Bob Hinden.  Agreed we don't need IANA to do this.
    I prefer to think of it as WG space not jims space.

2.  I think we need to make a commitment to IPv6 at IANA and have
    an address space set up.

    o I hope we are to use the International registries this needs
      to be defined for IPv6 (see Yakov Rekhter addr proposal).
    o I would like to see providers use real IPv6 addresses to route
      my IPv6 test packets.  I perceive we move to a model where we will
      get our IPv6 addresses from our providers. We can give the
      providers our prototypes for testing too.

3.  I have real end-users asking me how they get an IPv6 address space
    for testing and have already been asked for my implementation of 
    IPv6 binaries on ALpha UNIX to begin testing.  I think this should 
    be done with address space from IANA not jims or WG address space.

4.  Transition is critical for IPv4-to-IPv6.  I think there needs to be
    thought by IANA experts for IPv6-Only addresses and what role the
    IPv4-compatible IPv6 addresses will play against each other and
    routability.  Is ::16.12.34.2 a flat space with zero prefix? I think
    so but not sure yet.

5.  Politically I don't believe CIDR is going to last the present
    predictions and we need to get the show on the road here.  IANA
    setting up address space, standards going to proposed,
    interoperability demos at trade-shows all will pick up the momentum
    to get us to IPv6.  I think if we start now we can be there in force
    by 1998.  Early adopters can be testing I think by mid 96 and 97 via
    prototypes and maybe first wave of products for transition.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 07:50:50 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11355; Fri, 18 Aug 95 07:50:50 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11349; Fri, 18 Aug 95 07:50:41 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA05719; Fri, 18 Aug 1995 07:39:35 -0700
Received: from rodan.UU.NET by mercury.Sun.COM (Sun.COM)
	id HAA20767; Fri, 18 Aug 1995 07:39:31 -0700
Received: from localhost by rodan.UU.NET with SMTP 
	id QQzdig24752; Fri, 18 Aug 1995 10:36:03 -0400
Message-Id: <QQzdig24752.199508181436@rodan.UU.NET>
To: bound@zk3.dec.com
Cc: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 544) Re:  PC Week TCP/IP EXPO IPv6 Article fyi ................ 
In-Reply-To: Your message of "Fri, 18 Aug 1995 09:25:21 EDT."
             <9508181325.AA10654@xirtlu.zk3.dec.com> 
Date: Fri, 18 Aug 1995 10:36:02 -0400
From: "Mike O'Dell" <mo@uunet.uu.net>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Heartiest congratulations to all involved in the connectathon,
and an especial thank-you to you, Jim, for making it happen.
Very nice work, and very good ink.

	cheers,
	-mo
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 08:04:58 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11370; Fri, 18 Aug 95 08:04:58 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11364; Fri, 18 Aug 95 08:04:50 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06823; Fri, 18 Aug 1995 07:53:44 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id HAA23095; Fri, 18 Aug 1995 07:53:44 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA20310; Fri, 18 Aug 1995 07:46:38 -0700
Received: by xirtlu.zk3.dec.com; id AA13106; Fri, 18 Aug 1995 10:46:36 -0400
Message-Id: <9508181446.AA13106@xirtlu.zk3.dec.com>
To: "Mike O'Dell" <mo@uunet.uu.net>
Cc: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 545) Re:  PC Week TCP/IP EXPO IPv6 Article fyi ................ 
In-Reply-To: Your message of "Fri, 18 Aug 95 10:36:02 EDT."
             <QQzdig24752.199508181436@rodan.UU.NET> 
Date: Fri, 18 Aug 95 10:46:30 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

thanks mike all the folks worked real hard.  I did say the IETF did a
wonderful job and later in my presentation.  but that did not make it.
but i did get the idea of "working group" across and that got in there
so all on this list should feel proud too.  you designed what we showed.

/jim 
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 09:08:15 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11406; Fri, 18 Aug 95 09:08:15 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11400; Fri, 18 Aug 95 09:08:07 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13344; Fri, 18 Aug 1995 08:57:00 -0700
Received: from VNET.IBM.COM by mercury.Sun.COM (Sun.COM)
	id IAA06067; Fri, 18 Aug 1995 08:57:00 -0700
Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6735;
   Fri, 18 Aug 95 11:56:55 EDT
Received: by RTP (XAGENTA 4.0) id 4253; Fri, 18 Aug 1995 11:56:42 -0400 
Received: by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA13478; Fri, 18 Aug 1995 11:56:45 -0400
Message-Id: <9508181556.AA13478@cichlid.raleigh.ibm.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 546) FYI: Last Call: RIPng for IPv6 to Proposed Standard
Date: Fri, 18 Aug 95 11:56:44 -0500
From: "Thomas Narten" <narten@VNET.IBM.COM>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

FYI: I sent the following message out earlier today.

To: iesg@cnri.reston.va.us
cc: ietf-rip@xylogics.com
Subject: Re: Last Call: RIPng for IPv6 to Proposed Standard
Date: Fri, 18 Aug 95 11:54:11 -0500
From: Thomas Narten <narten>

I'd like to formally object to having RIPng promoted to PS in its
current form. Note that this is my first reading of the draft, so the
WG has not (as far as I know -- I am not on the RIPng list) been made
aware of this issue or discussed it.  The issue I'm raising centers
around what source address a router uses in outgoing routing updates.

Neighbor Discovery (ND) has made the decision that hosts are to know
of routers only through the router's link-local address. For example,
if a router R1 sends a redirect to host X telling it to use router R2,
the router must specify R2 by R2's link-local address.  This requires
that R1 know R2's link-local address. How a router learns the
link-local addresses of other routers is beyond the scope of ND and is
a (routing) protocol-specific issue.

In the case of RIPng, I recommend that it be mandatory that the source
address of RIP updates always be the router's "designated address" (as
defined in ND). In practice, the designated address is the link-local
address of the sending interface. That way RIP routers would
automatically know the link-local addresses of its neighboring
routers.  At a minimum, this would require some rewording of the draft
(detailed comments are appended). For example, the current draft says
that routers send separate updates for *each* of its configured
addresses. Sending a single update from the link-local address
eliminates this requirement (I believe).

[Remainder of note omitted...]
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Fri Aug 18 11:05:10 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11538; Fri, 18 Aug 95 11:05:10 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11532; Fri, 18 Aug 95 11:05:01 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00139; Fri, 18 Aug 1995 10:53:52 -0700
Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM)
	id KAA07567; Fri, 18 Aug 1995 10:53:45 -0700
From: bmanning@ISI.EDU
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA27051>; Fri, 18 Aug 1995 10:52:13 -0700
Posted-Date: Fri, 18 Aug 1995 10:49:37 -0700 (PDT)
Message-Id: <199508181749.AA12632@zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
	id <AA12632>; Fri, 18 Aug 1995 10:49:37 -0700
Subject: (IPng 547) Re:  IPv6 Address Space and Architecture Spec
To: bound@zk3.dec.com
Date: Fri, 18 Aug 1995 10:49:37 -0700 (PDT)
Cc: ipng@sunroof2.Eng.Sun.COM
In-Reply-To: <9508181301.AA09820@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 18, 95 09:01:41 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> I am going to contact Bob Hinden off line as I may be able to run the
> first root name server for IPv6-INT until it becomes an administrative
> major task (which I think will take at least six months).  So we have an
> IPv6 name space on the Internet.  It would use v4 protocol for access
> initially.  

I offered to do this about 6 months back.  I still have not been able to
get the code to support IPv6 RRs.  The claim is that it is "waiting for 
submission to the regular BIND distribution".  

If I can get the code, I'll get it put up and there can be a real 
DNS tree.  I'll even work on getting the code into the "real" root
nameservers.

--bill
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sat Aug 19 01:59:11 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11939; Sat, 19 Aug 95 01:59:11 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA11933; Sat, 19 Aug 95 01:59:01 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA07368; Sat, 19 Aug 1995 01:47:57 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id BAA22882; Sat, 19 Aug 1995 01:47:56 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA03149; Sat, 19 Aug 1995 01:40:27 -0700
Received: by xirtlu.zk3.dec.com; id AA29306; Sat, 19 Aug 1995 04:40:24 -0400
Message-Id: <9508190840.AA29306@xirtlu.zk3.dec.com>
To: "Thomas Narten" <narten@VNET.IBM.COM>
Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com
Subject: (IPng 548) Re:  FYI: Last Call: RIPng for IPv6 to Proposed Standard 
In-Reply-To: Your message of "Fri, 18 Aug 95 11:56:44 CDT."
             <9508181556.AA13478@cichlid.raleigh.ibm.com> 
Date: Sat, 19 Aug 95 04:40:18 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

I support Tom completely.  They must use the designated address or
explain why we are wrong in IPng.  I am a little pissed that RIPng was
not even sent to this list before even going to proposed std.  Its not
like other groups have IPv6 expertise yet and I think that would have
been courteuous.  But also I think the real important spec is OSPF for
IPv6.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sat Aug 19 11:21:37 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12040; Sat, 19 Aug 95 11:21:37 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12034; Sat, 19 Aug 95 11:21:29 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16984; Sat, 19 Aug 1995 11:10:21 -0700
Received: from atlas.xylogics.com by mercury.Sun.COM (Sun.COM)
	id LAA16995; Sat, 19 Aug 1995 11:10:16 -0700
Received: by atlas.xylogics.com id AA29994 (5.65c/UK-2.1-950310);
	  Sat, 19 Aug 1995 14:08:38 -0400
From: Gary Scott Malkin <gmalkin@xylogics.com>
Date: Sat, 19 Aug 1995 14:08:38 -0400
Message-Id: <29994.199508191808@atlas.xylogics.com>
To: bound@zk3.dec.com
Cc: ipng@sunroof.Eng.Sun.COM
In-Reply-To: bound@zk3.dec.com's message of Sat, 19 Aug 95 04:40:18 -0400 <9508190840.AA29306@xirtlu.zk3.dec.com>
Subject: (IPng 549) Re:  FYI: Last Call: RIPng for IPv6 to Proposed Standard 
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

When the RIPng draft was first published, a message went to the
ietf-announce, ietf-rip and ipng mailing lists.  The draft is too
large to send on the lists themselves; it would be wasted bandwidth.

As to the comment about designated addresses, I have no problem
changing this.  If someone will send me the proper text, I'll be
glad to update the draft.

----------------------------------------------------------------------
Gary Malkin                                          Cheap, Fast, Good
(617) 272-8140                                       Pick two!
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 20 06:39:11 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12180; Sun, 20 Aug 95 06:39:11 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12174; Sun, 20 Aug 95 06:39:03 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12276; Sun, 20 Aug 1995 06:27:55 -0700
Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM)
	id GAA20840; Sun, 20 Aug 1995 06:27:56 -0700
Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com
	with SMTP id JAA13603 for <ipng@sunroof.eng.sun.com>; Sun, 20 Aug 1995 09:27:40 -0400
Message-Id: <199508201327.JAA13603@dylan.mindspring.com>
X-Sender: sthomas@mindspring.com
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 20 Aug 1995 09:12:24 -0400
To: ipng@sunroof.Eng.Sun.COM
From: Stephen Thomas <sthomas@mindspring.com>
Subject: (IPng 550) Token Ring Anyone?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Gentle Readers:

Is anyone working on an IPv6-over-Token Ring draft? I'll
be happy to put one together, and I thought I'd check to
be sure no one else has the same idea.

It seems like the big issue is multicast mapping. I'd like
someone to convince me otherwise, but the IEEE multicast
address mapping probably isn't reasonable. Many token ring
adapters cannot recognize any multicast MAC addresses,
supporting IBM's functional addresses instead. Since there
are only 31 possible functional addresses (and many are
spoken for by NetBIOS and such), IP can only afford to use
a single functional address for all multicast traffic.

I understand the 802.5 folks are as unhappy about this as
we are, and, unless someone tells me that he/she's already
working on a token ring draft, I'll contact the 802.5
folks right away. Crossing my fingers, I'll hope they have
a clever way out.

One data point. How does the group feel about RFC 1469's
approach? That spec calls for the multicast mapping to be
a configuration option, with the functional address as a
default. If configured differently though, the spec allows
multicast mapping via multicast MAC addresses.

Personally, I'm not very fond of this approach; it gives
users the option of unconfiguring interoperability. Note
that every system on the subnet has to have the same idea
of multicast mapping, so it's not possible to configure
some one way and others differently. IMHO, if we're going
to have different options, then we must have a way for the
nodes to automatically detect which option is in use and
adapt accordingly.

Comments, thoughts?

--Stephen

________________________
Stephen A. Thomas
4397 Windsor Oaks Circle
Marietta, GA  30066-2387
E-mail: s.thomas@acm.org

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 20 06:46:23 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12193; Sun, 20 Aug 95 06:46:23 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12187; Sun, 20 Aug 95 06:46:15 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12412; Sun, 20 Aug 1995 06:35:07 -0700
Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM)
	id GAA21207; Sun, 20 Aug 1995 06:35:08 -0700
Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com
	with SMTP id JAA14649 for <ipng@sunroof.eng.sun.com>; Sun, 20 Aug 1995 09:35:05 -0400
Message-Id: <199508201335.JAA14649@dylan.mindspring.com>
X-Sender: sthomas@mindspring.com
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 20 Aug 1995 09:19:44 -0400
To: ipng@sunroof.Eng.Sun.COM
From: Stephen Thomas <sthomas@mindspring.com>
Subject: (IPng 551) Frame Relay Anyone?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Gentle Readers:

Is anyone working on an IPv6-over-Frame Relay draft?
I thought I'd try putting one together and wanted to
make sure I'm not duplicating anyone else's efforts.

If I do proceed, there are a couple of issues. I
haven't been following Frame Relay real closely in
the last year, so I'm not sure how they stand. If
someone else can fill me in, it would save me
from some research.

1) Frame relay multicast. I understand some carriers
   are providing multicast now. Will it be available
   enough to use for IPv6 multicast, or do we need
   a fallback like ATM's broadcast unknown server?
   Also, is there any special format for multicast
   DLCIs? (So we can algorithmically map between
   them and IPv6 addresses.)

2) Link-local tokens. Any ideas on a link local token?
   Are SVCs common enough that we can use their identifier?
   And what type of address do SVCs use?

Comments or thoughts?

--Stephen

________________________
Stephen A. Thomas
4397 Windsor Oaks Circle
Marietta, GA  30066-2387
E-mail: s.thomas@acm.org

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 20 07:09:39 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12217; Sun, 20 Aug 95 07:09:39 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12211; Sun, 20 Aug 95 07:09:31 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12896; Sun, 20 Aug 1995 06:58:23 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id GAA21799; Sun, 20 Aug 1995 06:58:24 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA09821; Sun, 20 Aug 1995 06:50:52 -0700
Received: by xirtlu.zk3.dec.com; id AA11494; Sun, 20 Aug 1995 09:50:48 -0400
Message-Id: <9508201350.AA11494@xirtlu.zk3.dec.com>
To: Gary Scott Malkin <gmalkin@xylogics.com>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 552) Re: FYI: Last Call: RIPng for IPv6 to Proposed Standard 
In-Reply-To: Your message of "Sat, 19 Aug 95 14:08:38 EDT."
             <29994.199508191808@atlas.xylogics.com> 
Date: Sun, 20 Aug 95 09:50:42 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Gary,

thanks for the response.  My other fear is we have not seen the latest
ND spec and there were still some outstanding issues.  On the flip side
I think its good your driving this to proposed and we should not be
holding you up either because ND has not come out since May 95.

thanks again,
/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 21 02:14:18 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12531; Mon, 21 Aug 95 02:14:18 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12525; Mon, 21 Aug 95 02:14:05 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11978; Mon, 21 Aug 1995 02:02:57 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id CAA20911; Mon, 21 Aug 1995 02:02:49 -0700
Message-Id: <m0skT66-00013gC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 553) Re: FYI: Last Call: RIPng for IPv6 to Proposed Standard
To: bound@zk3.dec.com
Date: Mon, 21 Aug 1995 10:24:46 +0100 (BST)
Cc: narten@VNET.IBM.COM, ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508190840.AA29306@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Aug 19, 95 04:40:18 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> I support Tom completely.  They must use the designated address or
> explain why we are wrong in IPng.  I am a little pissed that RIPng was
> not even sent to this list before even going to proposed std.  Its not
> like other groups have IPv6 expertise yet and I think that would have
> been courteuous.  But also I think the real important spec is OSPF for
> IPv6.

I agree with the problems with RIPng. However RIPng is important for the
same reasons as BSD mrouted. Its also dangerous for the same reasons -
that its quick to implement and easy to debug and sort of does the job
while developing.

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 21 08:46:42 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12591; Mon, 21 Aug 95 08:46:42 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12585; Mon, 21 Aug 95 08:46:28 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA00301; Mon, 21 Aug 1995 08:35:19 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id IAA00522; Mon, 21 Aug 1995 08:35:18 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id LAA10296 for ipng@sunroof.Eng.Sun.COM; Mon, 21 Aug 1995 11:35:33 -0400 (EDT)
Date: Mon, 21 Aug 1995 11:35:33 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508211535.LAA10296@newdev.harvard.edu>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 554) routing for IPv6
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk



At the request of the working group meeting in Stockholm I asked the
Routing Area Director for a report on the status of routing for IPv6. 
Here is his response.

Scott

---

From jhalpern@Newbridge.COM Mon Aug 21 11:24:22 1995
Date: Mon, 21 Aug 1995 11:22:51 +0500
From: jhalpern@Newbridge.COM (Joel Halpern)
To: sob@harvard.edu
Subject: Routing for IPv6
X-Sun-Charset: US-ASCII
Content-Length: 772

1) RIPng is out for last call.  After some minor changes, I expect it will
    become a proposed standard.  It will also be slightly delayed awaiting
    an appropriate appplicability statement.

2) For OSPFng, there is an Internet Draft.  The working group has not yet
    asked for advancement, but presumably will soon.

3) For Inter-domain routing, the plan is to use IDRP.  There is an ID on
    IDRP for IPv6.
    To date, there are two independent implementations of IDRP.
    One was done by IBM, and one by MERIT.  Both are reported to be part
    of gated.  I am re-checking this as it does not appear in my copy.
    There is reported to be a earuopean vendor who has a version as well.

Yours,
Joel M. Halpern				jhalpern@newbridge.com
Newbridge Networks Inc.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 21 09:25:13 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12628; Mon, 21 Aug 95 09:25:13 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12622; Mon, 21 Aug 95 09:25:04 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA04953; Mon, 21 Aug 1995 09:13:53 -0700
Received: from venera.isi.edu by mercury.Sun.COM (Sun.COM)
	id JAA08109; Mon, 21 Aug 1995 09:13:52 -0700
From: bmanning@ISI.EDU
Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22)
	id <AA14580>; Mon, 21 Aug 1995 09:13:51 -0700
Posted-Date: Mon, 21 Aug 1995 09:11:13 -0700 (PDT)
Message-Id: <199508211611.AA16408@zed.isi.edu>
Received: by zed.isi.edu (5.65c/4.0.3-4)
	id <AA16408>; Mon, 21 Aug 1995 09:11:13 -0700
Subject: (IPng 555) Re:  routing for IPv6
To: sob@newdev.harvard.edu (Scott Bradner)
Date: Mon, 21 Aug 1995 09:11:13 -0700 (PDT)
Cc: ipng@sunroof.Eng.Sun.COM
In-Reply-To: <199508211535.LAA10296@newdev.harvard.edu> from "Scott Bradner" at Aug 21, 95 11:35:33 am
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> 3) For Inter-domain routing, the plan is to use IDRP.  There is an ID on
>     IDRP for IPv6.
>     To date, there are two independent implementations of IDRP.
>     One was done by IBM, and one by MERIT.  Both are reported to be part
>     of gated.  I am re-checking this as it does not appear in my copy.
>     There is reported to be a earuopean vendor who has a version as well.
> 

Thanks for the update.   I do have a minor problem, perhaps conceptual.
My understanding is that IDRP shares that same characterisics as BGP.
And as we all know, BGP is effectivly a point2point protocol.  What
affect will this protocol feature have given the  general concept of 
dynamic renumbering and address configuration in IPv6?

--bill
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 21 10:56:32 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12787; Mon, 21 Aug 95 10:56:32 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12781; Mon, 21 Aug 95 10:56:19 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19451; Mon, 21 Aug 1995 10:45:09 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id KAA06563; Mon, 21 Aug 1995 10:44:12 -0700
Message-Id: <m0skbEq-00013gC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 556) Two comments wrt drafts I sent
To: ipng@sunroof.Eng.Sun.COM
Date: Mon, 21 Aug 1995 19:06:17 +0100 (BST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

[Two comments included, look below this for the other]
 
WRT: draft-ietf-ipngwg-ipv6-spec-02.txt
                IPv6 Program Interfaces for BSD Systems
                   <draft-ietf-ipngwg-bsd-api-02.txt>


This is a set of feedback now I have started implementing the beginnings of
IPv6 under Linux. It covers various minor issues and one major pending
catastrophe that probably wants avoiding.

>        struct in_addr6 {
>                u_char  s6_addr[16];    /* IPv6 address */
>        }

First minor point. The RFC should specify the types in terms of ANSI C
rather than BSD tradition. We all know what a u_char is, but it is not a
formal standard way to refer to this.


>structure in <netinet/in.h> to carry IPv6 addresses:
>
>        struct sockaddr_in6 {
>                u_short         sin6_family;    /* AF_INET6 */
>                u_short         sin6_port;      /* Transport layer port # */
>                u_long          sin6_flowinfo;  /* IPv6 flow information */
>                struct in_addr6 sin6_addr;      /* IPv6 address */
>        };

The structure should not be specified to be in netinet/in.h merely to
be defined directly or indirectly as a result of including this file.
In Linux it will be in the kernel headers and included from there by
netinet/in.h

>The sin6_port field is used to store the 16-bit UDP or TCP port
>number.  This field is used in the same way as the sin_port field of
>the sockaddr_in structure.  The port number is stored in network byte
>order.

This is the major bug. Elsewhere you state that the sin6_port need not
be a 16bit value. A specific size needs to be specified or nobody knows 
which of ntohs/ntohl to use short of a messy sizeof() check each time, which
is bound to go wrong. Far better a 16 or 32 bit value is chosen. I would
favour 32 for expansion reasons. This is actually very bad because things
like 47 bits of sin6_port are perfectly allowed by the current draft..

>The ordering of elements in this structure is specifically designed so
>that the sin6_addr field will be aligned on a 64-bit boundary.  This is
>done for optimum performance on 64-bit architectures.

Which is not true if people use the 32bit port as is allowed but I think
that may be obvious enough. It should state whether re-ordering the fields
other than the family is legal.

>To create an IPv6/UDP socket, applications make the call:
>
>        s = socket (PF_INET6, SOCK_DGRAM, 0);
>

Does this mean the use of  s=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP) is
deprecated, and if so what happens when we get multiple datagram protocols
in the future ?

>Once the application has created a PF_INET6 socket, it must use the
>sockaddr_in6 address structure when passing addresses in to the system.
>The functions which the application uses to pass addresses into the
>system are:

Misleading. You have an option to switch to IPv4 addresses lower down.

>        int is_ipv4_addr (const struct in_addr6 *ap);

The function name with a_b_c_d is totally out of keeping with getsockname
not get_sock_name and the other functions. I thing this should be
defined as isipv4addr() for consistency with the existing API. It should
also be permissible for it to be a macro. This isnt an issue to me as gcc
has inline functions, but an issue to some potentially.

>or receives a UDP packet, it may determine whether the peer is an IPv4
>node by applying the is_ipv4_addr() function to the address returned
>by accept() or recvfrom().

Does this imply the day a given machine is switched to IPv6 from IPv4/IPv6
split it will be renumbered ?

>Unix allows open sockets to be passed across an exec() call.  It is a
>relatively common application practice to pass open sockets across
>exec() calls.  Because of this, it is possible for an application

Also via the other descriptor passing mechanisms (AF_UNIX socket etc).
Probably not worth noting for completeness - just thrown in.

>transmitted packets of an actively opened TCP connection by setting the
>sin6_flowinfo field of the destination address sockaddr_in6 structure
>passed in the connect() function.  An application may specify the flow
>label and priority to use in transmitted UDP packets by setting the
>sin6_flowinfo field of the destination address sockaddr_in6 structure
>passed in the sendto() function.  If an application does not care what

or sendmsg()

We should also specify an official set of #define names and values for these
properties so that there is a consistent

	x.flowinfo = IPV6_PRIORITY_URGENT|flow_value;

type format across systems.


>The macro definition for IP_RCVSRCRT is in <netinet/in.h>.

Again 'is defined as a result of including..'

>A new setsockopt() option is used to control the hop limit used in
>outgoing unicast IPv6 packets.  The name of this option is
>IP_UNICAST_HOPS, and it is used at the IPPROTO_IP layer.  The macro
>definition for IP_UNICAST_HOPS resides in the <netinet/in.h> header

As a result of including again. This is directly analagous to IP_TTL
so I'd probably do this as the same option different name. I think the
phrase 'new option' does not in any way suggest this is prohibited which is
good.

>        IP_MULTICAST_LOOP       Controls whether outgoing multicast
>                                packets sent should be delivered back to
>				 the local application. A toggle

So which is true and which is false. Also does this work on a per socket
or per host basis. Or should both be settable. Maybe we should have names
for the settings defined ?

>          struct hostent *hostname2addr(const char *name, int af);

It should specify where the ANSI C prototype to this function will be
found(ie what to include for it) - that goes for the other new functions
and probably for the traditional ones too.

>This new function looks up the given name in the name service and
>returns the completed hostent structure if the lookup succeeds, and NULL
>otherwise.  The name argument is the domain name of the host to look up.

This would be better phrased as 'in all the available resolution services on
this host' - we may not have DNS during a boot, there may be NIS or local
maps checked first.  The design of these functions is also flawed from a
threading point of view. A buffer should be passed in, or a free function
provided. Finally if the buffer is owned by the library would a const struct
* return be better.

>function does not modify the storage pointed to by ap if the conversion
>fails. The application must ensure that the buffer referred to by ap is
>large enough to hold the converted address.

In which case there should be a query maximum length function too so
multiprotocol applications don't have to be telepathic.

The remaining big issue is raw sockets. I interpret IPV6 raw sockets as
returning you the headers and complete frame if it contains any headers
matching your type, or for IPPROTO_RAW anyway. The sending semantics are
still a very open issue. Having a defined raw behaviour is important for
tools like traceroute/ping.




WRT: draft-ietf-ipngwg-ipv6-spec-02.txt


This is a submission for a possible change to the IP fragment header to
improve performance on systems that wish to preallocate linear buffers for
fragment reassembly - which in itself is a performance advantage for many
architectures and is the preferred way to deal with IPv6 in both the Linux
operating system and other routing hardware I am involved with development
of but am not at liberty to discuss further.

>In a packet with a Fragment header, the Payload Length field of the IPv6
>header contains the length of that packet only (excluding the IPv6
>header itself), not the length of the original, unfragmented payload.

A variety of architectures would benefit from knowing the full packet
length in advance. This includes all systems that avoid chains of buffers
either directly for performance advantages or in order to make effective use
of non scatter gather DMA driven devices. While it is currently possible to
arrange this for IPv4 in 'most' cases needs by sending the fragments in 
reverse order (also good for performance[*]) knowing the full packet length
allows the receiver

1.	To preallocate fixed length buffers of the appropriate size for
the completed frame and not have to use chains of buffer fragments with
their associated performance costs while accumulating the frame.

2.	To discard fragments in advance when the total frame is larger
than it is prepared to accept anyway.

3.	To make a more accurate time and space resource cost assesment of
frames when deciding which incomplete frames to discard to keep within
resource constraints.

I would thus suggest that adding a 2 byte total length field is the
right thing to do. One possible approach would be


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |.|J|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :Total Length/Fragment High word:
   +-------------------------------+


Where the J bit indicates a fragmented jumbogram (which could now
become legal), in which case the Fragment high word is the top 16
bits of the fragment offset and the length field is un-needed because the
Jumbo payload option carries the length. A fragmented Jumbogram constructed
in this fashion would occupy no more space than a single jumbogram and thus
be practical to implement from a memory point of view. While many people
hold fragmented jumbograms to be bad due to the number of fragments, on the
hypothetical network with 70K frames, a 280K frame is less fragments than a
typical NFS packet on a 1500 byte/frame ethernet and does not seem
unreasonable. Obviously an implementation must apply common sense to such
matters based on the path MTU for a route.

If the J bit is clear then the frame is not a jumbogram and the word carries
the total frame length information for those hosts who wish to make use of it.


[*] By sending the fragments in reverse order it is easy to implement a
combined copy/checksum/fragment pass. The final checksum is ready when
the user data has been copy/checksummed into all fragments. Only then
can the first fragment checksum be filled in and sent.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 21 11:55:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12932; Mon, 21 Aug 95 11:55:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA12926; Mon, 21 Aug 95 11:55:21 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28712; Mon, 21 Aug 1995 11:44:08 -0700
Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM)
	id LAA20574; Mon, 21 Aug 1995 11:44:00 -0700
Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
	id AA02465; Mon, 21 Aug 95 14:42:38 EDT
Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1)
	id AA17340; Mon, 21 Aug 95 14:43:50 EDT
Date: Mon, 21 Aug 95 14:43:50 EDT
From: dhaskin@BayNetworks.com (Dimitry Haskin)
Message-Id: <9508211843.AA17340@BayNetworks.com>
To: iialan@iiit.swan.ac.uk
Subject: (IPng 557) Re:  Two comments wrt drafts I sent
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> From: iialan@iiit.swan.ac.uk (Alan Cox)
> Subject: (IPng 556) Two comments wrt drafts I sent
> To: ipng@sunroof.Eng.Sun.COM
> Date: Mon, 21 Aug 1995 19:06:17 +0100 (BST)
> 
> WRT: draft-ietf-ipngwg-ipv6-spec-02.txt
> 
> 
> This is a submission for a possible change to the IP fragment header to
> improve performance on systems that wish to preallocate linear buffers for
> fragment reassembly - which in itself is a performance advantage for many
> architectures and is the preferred way to deal with IPv6 in both the Linux
> operating system and other routing hardware I am involved with development
> of but am not at liberty to discuss further.
> 
> >In a packet with a Fragment header, the Payload Length field of the IPv6
> >header contains the length of that packet only (excluding the IPv6
> >header itself), not the length of the original, unfragmented payload.
> 
> A variety of architectures would benefit from knowing the full packet
> length in advance. This includes all systems that avoid chains of buffers
> either directly for performance advantages or in order to make effective use
> of non scatter gather DMA driven devices. While it is currently possible to
> arrange this for IPv4 in 'most' cases needs by sending the fragments in 
> reverse order (also good for performance[*]) knowing the full packet length
> allows the receiver
> 
> <rest omitted>

Alan,

While I sympathize with your request to provide the full packet length in
the fragment header, I have to point out that it will become a problem if
we ever decide to define IPv4-to-IPv6 translation.  Translators would need
to fully re-assemble an IPv6 datagram before it can be converted to IPv6
format.

One possible compromise is to define that a zero value of the Total Length
field in a Fragment header indicates the total length is not provided.
But, since in this case forwarders need to be capable to deal with
fragments of unspecified length packets, I afraid it may defeat the very
purpose of your proposal.

Dimitry
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 21 17:37:52 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13175; Mon, 21 Aug 95 17:37:52 PDT
Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13169; Mon, 21 Aug 95 17:37:41 PDT
Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA24081; Mon, 21 Aug 1995 17:26:16 -0700
Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA04784; Mon, 21 Aug 1995 17:29:45 -0700
Date: Mon, 21 Aug 1995 17:29:45 -0700
From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan)
Message-Id: <9508220029.AA04784@kandinsky.Eng.Sun.COM>
To: iialan@iiit.swan.ac.uk
Subject: (IPng 558) re: Two comments wrt drafts I sent
Cc: ipng@sunroof
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Alan - Thanks for your detailed comments!

> This is a set of feedback now I have started implementing the beginnings of
> IPv6 under Linux. It covers various minor issues and one major pending
> catastrophe that probably wants avoiding.
> 
> >        struct in_addr6 {
> >                u_char  s6_addr[16];    /* IPv6 address */
> >        }
> 
> First minor point. The RFC should specify the types in terms of ANSI C
> rather than BSD tradition. We all know what a u_char is, but it is not a
> formal standard way to refer to this.

What would you suggest we use instead of u_char?

Also, note that earlier on in the spec we try to make the point that the
types used in this spec (e.g. u_char) are just examples.
Implementations are free to use other types if they wish.

> >structure in <netinet/in.h> to carry IPv6 addresses:
> >
> >        struct sockaddr_in6 {
> >                u_short         sin6_family;    /* AF_INET6 */
> >                u_short         sin6_port;      /* Transport layer port # */
> >                u_long          sin6_flowinfo;  /* IPv6 flow information */
> >                struct in_addr6 sin6_addr;      /* IPv6 address */
> >        };
> 
> The structure should not be specified to be in netinet/in.h merely to
> be defined directly or indirectly as a result of including this file.
> In Linux it will be in the kernel headers and included from there by
> netinet/in.h

Sounds like a reasonable suggestion.  I'll change the wording to
something like this:

	The IPv6 address structure is defined by including the header
	file <netinet/in.h>.

> >The sin6_port field is used to store the 16-bit UDP or TCP port
> >number.  This field is used in the same way as the sin_port field of
> >the sockaddr_in structure.  The port number is stored in network byte
> >order.
> 
> This is the major bug. Elsewhere you state that the sin6_port need not
> be a 16bit value. A specific size needs to be specified or nobody knows 
> which of ntohs/ntohl to use short of a messy sizeof() check each time, which
> is bound to go wrong. Far better a 16 or 32 bit value is chosen. I would
> favour 32 for expansion reasons. This is actually very bad because things
> like 47 bits of sin6_port are perfectly allowed by the current draft..

I think the issue is that some machines might not be capable of
providing an addressable 16-bit word.  We want to leave some flexability
in the spec for those machines.  Our general intention here was that the
sin6_port would be the same size as the sin_port field of the
sockaddr_in struct.  And since you use the htons() and ntohs() functions
on the sin_port element, you would use the same functions on the
sin6_port field.

In leaving the door open for a field size larger than 16 bits, we were
not really thinking about providing hooks for a revised version of TCP
or UDP that had 32-bit port numbers.  Given that the API has to work
with today's TCP and UDP, which happens to use 16-bit port numbers, I'm
not sure what the implications of using a size larger size would be.
Would we need to define a new errno to handle the case where an
application passed in a port number greater than 65535?  EBADPORT?
	
I'm open to suggestions on how to word this better, but I think the spec
gets the intentions across fairly well as-is.

> >The ordering of elements in this structure is specifically designed so
> >that the sin6_addr field will be aligned on a 64-bit boundary.  This is
> >done for optimum performance on 64-bit architectures.
> 
> Which is not true if people use the 32bit port as is allowed but I think
> that may be obvious enough. It should state whether re-ordering the fields
> other than the family is legal.

We were not intending to prevent implementations from using whatever
order they please.  I'll add some wording to clarify this.

> >To create an IPv6/UDP socket, applications make the call:
> >
> >        s = socket (PF_INET6, SOCK_DGRAM, 0);
> >
> Does this mean the use of  s=socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP) is
> deprecated, and if so what happens when we get multiple datagram protocols
> in the future ?

This is just an example.  We certainly were not trying to disallow the
usage you cite.  I'll add the usage you give above as second example.

> >Once the application has created a PF_INET6 socket, it must use the
> >sockaddr_in6 address structure when passing addresses in to the system.
> >The functions which the application uses to pass addresses into the
> >system are:
> 
> Misleading. You have an option to switch to IPv4 addresses lower down.

Right.  I'll revise the wording.

> >        int is_ipv4_addr (const struct in_addr6 *ap);
> 
> The function name with a_b_c_d is totally out of keeping with getsockname
> not get_sock_name and the other functions. I thing this should be
> defined as isipv4addr() for consistency with the existing API.

I'm not sure I follow your point here.  Are you saying that we should
not use the underscore character in function names?  If so, why not?  Do
underscores cause some sort of problem, or are you just concerned with
the way the function looks?  To my mind, adding the uderscores makes the
function easier to read.

> It should
> also be permissible for it to be a macro. This isnt an issue to me as gcc
> has inline functions, but an issue to some potentially.

I think this is an implementation issue.  You are free to implement this
as a macro on your system.  All that matters is that applications that
use is_ipv4_addr() compile and run on your system.

> >or receives a UDP packet, it may determine whether the peer is an IPv4
> >node by applying the is_ipv4_addr() function to the address returned
> >by accept() or recvfrom().
> 
> Does this imply the day a given machine is switched to IPv6 from IPv4/IPv6
> split it will be renumbered ?

No.  It only implies that the program can tell whether an IPv4 or IPv6
packet was received by applying the is_ipv4_addr() function to the
address that was returned.

> >Unix allows open sockets to be passed across an exec() call.  It is a
> >relatively common application practice to pass open sockets across
> >exec() calls.  Because of this, it is possible for an application
> 
> Also via the other descriptor passing mechanisms (AF_UNIX socket etc).
> Probably not worth noting for completeness - just thrown in.

Thanks!

> >transmitted packets of an actively opened TCP connection by setting the
> >sin6_flowinfo field of the destination address sockaddr_in6 structure
> >passed in the connect() function.  An application may specify the flow
> >label and priority to use in transmitted UDP packets by setting the
> >sin6_flowinfo field of the destination address sockaddr_in6 structure
> >passed in the sendto() function.  If an application does not care what
> 
> or sendmsg()

Yes.  Thanks for pointing that out.  I'll change the spec to indicate
that the sin6_flowinfo field can be set in the address buffers passed in
sendmsg() and recvmsg().

> We should also specify an official set of #define names and values for these
> properties so that there is a consistent
> 
> 	x.flowinfo = IPV6_PRIORITY_URGENT|flow_value;
> 
> type format across systems.

Yes, this was suggested by someone else in private e-mail too.  I'll
propose a set of macro definitions for the flow information properties.

> >The macro definition for IP_RCVSRCRT is in <netinet/in.h>.
> 
> Again 'is defined as a result of including..'

OK.  I'll update the spec.

> >A new setsockopt() option is used to control the hop limit used in
> >outgoing unicast IPv6 packets.  The name of this option is
> >IP_UNICAST_HOPS, and it is used at the IPPROTO_IP layer.  The macro
> >definition for IP_UNICAST_HOPS resides in the <netinet/in.h> header
> 
> As a result of including again. This is directly analagous to IP_TTL
> so I'd probably do this as the same option different name. I think the
> phrase 'new option' does not in any way suggest this is prohibited which is
> good.

OK.

> >        IP_MULTICAST_LOOP       Controls whether outgoing multicast
> >                                packets sent should be delivered back to
> >				 the local application. A toggle
> 
> So which is true and which is false. Also does this work on a per socket
> or per host basis. Or should both be settable. Maybe we should have names
> for the settings defined ?

Yes, the section of the spec on the IP multicast setsockopt() options
needs quite a bit more detail.

> >          struct hostent *hostname2addr(const char *name, int af);
> 
> It should specify where the ANSI C prototype to this function will be
> found(ie what to include for it) - that goes for the other new functions
> and probably for the traditional ones too.

OK.  Which header file would you suggest?  netdb.h?

> >This new function looks up the given name in the name service and
> >returns the completed hostent structure if the lookup succeeds, and NULL
> >otherwise.  The name argument is the domain name of the host to look up.
> 
> This would be better phrased as 'in all the available resolution services on
> this host' - we may not have DNS during a boot, there may be NIS or local
> maps checked first.  The design of these functions is also flawed from a
> threading point of view. A buffer should be passed in, or a free function
> provided. Finally if the buffer is owned by the library would a const struct
> * return be better.

Yes, it has been pointed out that the hostname2add() and addr2hostname()
functions as currently defined are not reentrant.  My co-authors and I
will propose a change to address this.

> >function does not modify the storage pointed to by ap if the conversion
> >fails. The application must ensure that the buffer referred to by ap is
> >large enough to hold the converted address.
> 
> In which case there should be a query maximum length function too so
> multiprotocol applications don't have to be telepathic.

I would argue that this is outside the scope of the IPv6 API spec.  This
spec does specify how long the address buffer must be in order to store
the ascii representation of an IPv6 address.  So IPv6 applications have
all the information they need.

> The remaining big issue is raw sockets. I interpret IPV6 raw sockets as
> returning you the headers and complete frame if it contains any headers
> matching your type, or for IPPROTO_RAW anyway. The sending semantics are
> still a very open issue. Having a defined raw behaviour is important for
> tools like traceroute/ping.

I think that raw sockets are also outside the scope of this spec too.

Bob.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 02:26:00 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13462; Tue, 22 Aug 95 02:26:00 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13456; Tue, 22 Aug 95 02:25:48 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14852; Tue, 22 Aug 1995 02:14:38 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id CAA17880; Tue, 22 Aug 1995 02:14:36 -0700
Message-Id: <m0skpl8-00013gC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 559) Re: Two comments wrt drafts I sent
To: Bob.Gilligan@Eng (Bob Gilligan)
Date: Tue, 22 Aug 1995 10:36:37 +0100 (BST)
Cc: iialan@iiit.swan.ac.uk, ipng@sunroof.Eng.Sun.COM
In-Reply-To: <9508220029.AA04784@kandinsky.Eng.Sun.COM> from "Bob Gilligan" at Aug 21, 95 05:29:45 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> > First minor point. The RFC should specify the types in terms of ANSI C
> > rather than BSD tradition. We all know what a u_char is, but it is not a
> > formal standard way to refer to this.
> 
> What would you suggest we use instead of u_char?

	unsigned char is the ANSI way of writing it. 

> Also, note that earlier on in the spec we try to make the point that the
> types used in this spec (e.g. u_char) are just examples.
> Implementations are free to use other types if they wish.

I missed that angle. It certainly isnt clear except for the ports

> In leaving the door open for a field size larger than 16 bits, we were
> not really thinking about providing hooks for a revised version of TCP
> or UDP that had 32-bit port numbers.  Given that the API has to work
> with today's TCP and UDP, which happens to use 16-bit port numbers, I'm
> not sure what the implications of using a size larger size would be.
> Would we need to define a new errno to handle the case where an
> application passed in a port number greater than 65535?  EBADPORT?

I think you missed the issue. If sin_port is an arbitary size how do you
know which of htons/htonl etc to use. If you wanted freedom like that
how about hton_port() ntoh_port() so that people can safely use them.
At the moment you would have to write a routine to get the length in bits
of the port and do your own portable reversal for arbitary bit length and
architecture, and include it in your program. Adding two #defines solves
that little problem.

> I'm open to suggestions on how to word this better, but I think the spec
> gets the intentions across fairly well as-is.

It does - but the effect is unfortunate.

> I'm not sure I follow your point here.  Are you saying that we should
> not use the underscore character in function names?  If so, why not?  Do
> underscores cause some sort of problem, or are you just concerned with
> the way the function looks?  To my mind, adding the uderscores makes the
> function easier to read.

Because no other BSD socket API uses the _ format. It's a consistency of
style issue, rather like using IsIPv4Address() would be wrong. All the
BSD api functions do not use the _ seperation of words (sendmsg/sendto/recvmsg/
recvfrom/getsockname/getpeername) not (send_msg/send_to/recv_msg/recv_from ..)

> > >          struct hostent *hostname2addr(const char *name, int af);
> > 
> > It should specify where the ANSI C prototype to this function will be
> > found(ie what to include for it) - that goes for the other new functions
> > and probably for the traditional ones too.
> 
> OK.  Which header file would you suggest?  netdb.h?

Sounds good enough to me - that seems to fit BSD traditional also. Also note
you have no '_' in names here either ;)

> > In which case there should be a query maximum length function too so
> > multiprotocol applications don't have to be telepathic.

> I would argue that this is outside the scope of the IPv6 API spec.  This
> spec does specify how long the address buffer must be in order to store
> the ascii representation of an IPv6 address.  So IPv6 applications have
> all the information they need.

You are creating an alleged generic API with a missing piece. The implementation
of a function to get the buffer length for an address family is sufficiently
important and trivial that I feel it is needed. If you propose to change the
hostname2addr() functions anyway this may no longer be an issue. All I propose
is
		size_t addrtonamesize(int af)
		{
			switch(af)
			{
				case AF_INET: return n;
				case AF_INET6: return m;
				case AF_AX25: return o;
				case AF_IPX: return p;
				default:
					return -ENOCLUE; 8)
			}
		}

Be in libc somewhere. That makes a huge difference for applications that
have to handle generic address formats, and removes hard coded assumptions 
from programs. It also means you can now swap a shared library if a new IPv6
address writing format came along which is longer than the current one and not
break applications.

> > still a very open issue. Having a defined raw behaviour is important for
> > tools like traceroute/ping.
> I think that raw sockets are also outside the scope of this spec too.

Ok I agree to disagree on that one. Lack of portability of tools does worry
me a little but trying to specify raw sockets is hard. I may send you a
proposal for a subset of raw socket behaviour for tool portability soon.

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 12:28:46 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13678; Tue, 22 Aug 95 12:28:46 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13672; Tue, 22 Aug 95 12:28:37 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA08221; Tue, 22 Aug 1995 12:17:25 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id MAA26551; Tue, 22 Aug 1995 12:17:19 -0700
Received: from muggsy.lkg.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA20466; Tue, 22 Aug 1995 11:57:44 -0700
Received:  from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
	id AA26795; Tue, 22 Aug 1995 14:57:38 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id PAA18769; Tue, 22 Aug 1995 15:01:43 GMT
Message-Id: <199508221501.PAA18769@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: ipng@sunroof.Eng.Sun.COM
Cc: dan@lkg.dec.com, bound@zk3.dec.com
Subject: (IPng 560) IPv6 fragments: can they overlap?
X-Mailer: exmh version 1.5omega 10/6/94
Date: Tue, 22 Aug 1995 15:01:42 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Yesterday on one of the FreeBSD/NetBSD/BSDI mailing lists (they all seem
to merge together after a while), there was a discussion about IP firewalls
and the use of overlapping fragments to maliciously tunnel through them.

The technique was that the first fragment contains a valid/allowed transport
header (and thus is allowed through the firewall), then a following fragment
(which is given a free ride since its header has been allowed through)
overlays that header with a new header which would not be otherwise allowed
by the firewall.  When the packet is reassembled at the destination, the
packet is delivered to some user other than what than was specified in the
original fragment (instead of port 53 for BIND, port ??? for whatever 
nefarious reason).

>From page 16 of draft-ietf-ipngwg-ipv6-spec-02.txt:

"The fragmentation algorithm is as follows:  The payload (including any
extension headers that need be processed only by the destination
node(s)) is divided into fragments, each, except possibly the last,
being an integer multiple of 8 octets long.  Each fragment is prepended
with a Fragment header and sent in a separate IPv6 packet.  The M
("more") flag is set to 1 on all fragments of the same payload except
the last.  The original..."

There is no mention (positive or negative) of whether payload fragments
can overlap each other.  Since in IPv6 the source is responsible for
fragmenting its packets, the source has complete control over the fragments
it sends and should be able to easily avoid sending overlapping fragments.

Could we add something like the following to the fragmentation section:

"As the payload is divided into fragments, each fragment must contain a
discrete portion of the payload.  Upon reassembly, if the contents of a
fragment overlaps that of an already processed fragment then that 
fragment option should be considered in error and an Parameter Problem ICMP
message shouldbe  sent".

In addition, not having to worry about overlapping fragments will permit
simpler reassembly code in most implementations.

Matt Thomas                          Internet:   thomas@lkg.dec.com
U*X Networking for OpenVMS           WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 12:45:29 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13698; Tue, 22 Aug 95 12:45:29 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13692; Tue, 22 Aug 95 12:45:20 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA10256; Tue, 22 Aug 1995 12:34:09 -0700
Received: from MVS.OAC.UCLA.EDU by mercury.Sun.COM (Sun.COM)
	id MAA00726; Tue, 22 Aug 1995 12:34:07 -0700
Message-Id: <199508221934.MAA00726@mercury.Sun.COM>
Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1)
   with BSMTP id 9506; Tue, 22 Aug 95 12:34:24 PST
Date:    Tue, 22 Aug 95 12:33 PDT
To: Matt Thomas <matt@LKG.DEC.COM>
Cc: ipng@SUNROOF.Eng.Sun.COM, dan@LKG.DEC.COM, bound@ZK3.DEC.COM
From: Michael Stein                        <OSYSMAS@MVS.OAC.UCLA.EDU>
Subject: (IPng 561) Re:  IPv6 fragments: can they overlap?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Not allowing overlapping fragments has another implication:

Say I send a packet in fragments and then decide that it didn't
make it and go to resend it.  If you don't allow overlapping
fragments then since the destination can't tell which fragments
were from the first try sending the packet and which were from
the second I'm being required to re-fragment the original packet
exactly the same way as the first time...

Is this a reasonable restriction?  Should it be stated somewhere?
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 12:48:12 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13710; Tue, 22 Aug 95 12:48:12 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13704; Tue, 22 Aug 95 12:47:59 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA10551; Tue, 22 Aug 1995 12:36:47 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id MAA01380; Tue, 22 Aug 1995 12:36:38 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id PAA01096; Tue, 22 Aug 1995 15:32:33 -0400 (EDT)
Date: Tue, 22 Aug 1995 15:32:33 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508221932.PAA01096@newdev.harvard.edu>
To: ipng@sunroof.Eng.Sun.COM, matt@lkg.dec.com
Subject: (IPng 562) Re:  IPv6 fragments: can they overlap?
Cc: bound@zk3.dec.com, dan@lkg.dec.com
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Matt,
	Is there a way that one could do this and still deal with duplicated
packets (fragments)?  Packet duplication is not all that uncommon in the net.

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:05:42 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13723; Tue, 22 Aug 95 13:05:42 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13717; Tue, 22 Aug 95 13:05:30 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12701; Tue, 22 Aug 1995 12:54:14 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id MAA06550; Tue, 22 Aug 1995 12:54:08 -0700
Subject: (IPng 563) Re: IPv6 fragments
To: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Date: Tue, 22 Aug 1995 15:54:18 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508222054.aa21340@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Matt, IPv6 fragments do not overlap, because there is NO, I REPEAT NO
INTERMEDIATE FRAGMENTATION!!!  Yes, this makes reassembly easier.

Mark, as far as resending, if you retransmit a packet, you're doing it at a
higher-level, like TCP.  IPv6 will assign a different identification value
to the next group of fragments.  If indeed the first fragmented datagram
didn't get reassembled, the second datagram will have to be reassembled only
from the second datagram itself.  You cannot mix-and-match fragment from the
original and the retransmission.

Scott, of course this works with network duplication of datagrams.  That's
one of the things IPv6 is supposed to deal with.  (If I get duplicate
fragments, I simply toss one out.)

IP and IPv6 are UNRELIABLE DATAGRAM PROTOCOLS.  Remember this.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:14:12 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13735; Tue, 22 Aug 95 13:14:12 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13729; Tue, 22 Aug 95 13:13:59 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13764; Tue, 22 Aug 1995 13:02:47 -0700
Received: from lobster.wellfleet.com by venus.Sun.COM (Sun.COM)
	id NAA10756; Tue, 22 Aug 1995 13:02:47 -0700
Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
	id AA03925; Tue, 22 Aug 95 16:00:10 EDT
Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1)
	id AA17626; Tue, 22 Aug 95 16:01:22 EDT
Date: Tue, 22 Aug 95 16:01:22 EDT
From: dhaskin@BayNetworks.com (Dimitry Haskin)
Message-Id: <9508222001.AA17626@BayNetworks.com>
To: matt@lkg.dec.com
Subject: (IPng 564) Re:  IPv6 fragments: can they overlap?
Cc: dan@lkg.dec.com, bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> Subject: (IPng 560) IPv6 fragments: can they overlap?
> Date: Tue, 22 Aug 1995 15:01:42 +0000
> From: Matt Thomas <matt@lkg.dec.com>
> 
> 
> Yesterday on one of the FreeBSD/NetBSD/BSDI mailing lists (they all seem
> to merge together after a while), there was a discussion about IP firewalls
> and the use of overlapping fragments to maliciously tunnel through them.
> 
> The technique was that the first fragment contains a valid/allowed transport
> header (and thus is allowed through the firewall), then a following fragment
> (which is given a free ride since its header has been allowed through)
> overlays that header with a new header which would not be otherwise allowed
> by the firewall.  When the packet is reassembled at the destination, the
> packet is delivered to some user other than what than was specified in the
> original fragment (instead of port 53 for BIND, port ??? for whatever 
> nefarious reason).
> 
> >From page 16 of draft-ietf-ipngwg-ipv6-spec-02.txt:
> 
> "The fragmentation algorithm is as follows:  The payload (including any
> extension headers that need be processed only by the destination
> node(s)) is divided into fragments, each, except possibly the last,
> being an integer multiple of 8 octets long.  Each fragment is prepended
> with a Fragment header and sent in a separate IPv6 packet.  The M
> ("more") flag is set to 1 on all fragments of the same payload except
> the last.  The original..."
> 
> There is no mention (positive or negative) of whether payload fragments
> can overlap each other.  Since in IPv6 the source is responsible for
> fragmenting its packets, the source has complete control over the fragments
> it sends and should be able to easily avoid sending overlapping fragments.
> 
> Could we add something like the following to the fragmentation section:
> 
> "As the payload is divided into fragments, each fragment must contain a
> discrete portion of the payload.  Upon reassembly, if the contents of a
> fragment overlaps that of an already processed fragment then that 
> fragment option should be considered in error and an Parameter Problem ICMP
> message shouldbe  sent".
> 
> In addition, not having to worry about overlapping fragments will permit
> simpler reassembly code in most implementations.
> 

Matt,

What if the overlapping fragments were due to duplication
in the network?  We should handle duplicate fragments without discarding
datagrams or generating ICMP messages.

Dimitry
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:19:18 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13754; Tue, 22 Aug 95 13:19:18 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13748; Tue, 22 Aug 95 13:19:05 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14518; Tue, 22 Aug 1995 13:07:52 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id NAA10055; Tue, 22 Aug 1995 13:07:50 -0700
Subject: (IPng 565) One more thing about overlapping fragments
To: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Date: Tue, 22 Aug 1995 16:08:02 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: Dan McDonald <danmcd@sundance.itd.nrl.navy.mil>,
        Ran Atkinson <rja@sundance.itd.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508222108.aa21465@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

I should've read Matt's note more closely, I forgot to address one thing.
Our reassembly code drops fragments that cause overlap, plain and simple.

One more thing, reassembly should be done before ANY OTHER options are
exercised, even hop-by-hop options which come before the fragment header.
Why?  Well, consider a packet that was authenticated.  The authentication
header comes AFTER fragmentation in the order of headers; this means that
authentication will only happen after reassembly.

Although no such hop-by-hop option exists yet, I'd imagine that someday
there might be one that I don't want to have executed at my endpoint until I
know that packet is authentic.  (Not to mention, if my datagram is chopped
into 2 pieces, my end system processes two copies of the hop-by-hop options
for the same datagram. :)

Otherwise, we may see fragmentation-based attacks on IPv6 systems, because
we don't authenticate fragmented datagrams; we only do end-to-end
authentication!

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:29:00 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13777; Tue, 22 Aug 95 13:29:00 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13771; Tue, 22 Aug 95 13:28:47 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15942; Tue, 22 Aug 1995 13:17:35 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id NAA12331; Tue, 22 Aug 1995 13:17:29 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA01334; Tue, 22 Aug 1995 16:17:41 -0400 (EDT)
Date: Tue, 22 Aug 1995 16:17:41 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508222017.QAA01334@newdev.harvard.edu>
To: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 566) Re: IPv6 fragments
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Scott, of course this works with network duplication of datagrams.

just to be clear, the fragment that comes in which would overlap with
a fragment already received is discarded.

the 1st letter in this thread seemed to say that the packet being reassembled
might be tossed &/or a warning message be generated - that seemed to be a
bit of a problem in the real world - did I misread?

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:31:22 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13789; Tue, 22 Aug 95 13:31:22 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13783; Tue, 22 Aug 95 13:31:13 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16165; Tue, 22 Aug 1995 13:19:58 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id NAA12716; Tue, 22 Aug 1995 13:19:55 -0700
Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA25842; Tue, 22 Aug 1995 13:11:18 -0700
Received:  from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
	id AA27096; Tue, 22 Aug 1995 16:11:13 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id QAA19333; Tue, 22 Aug 1995 16:15:20 GMT
Message-Id: <199508221615.QAA19333@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: Michael Stein <OSYSMAS@mvs.oac.ucla.edu>
Cc: ipng@sunroof.Eng.Sun.COM, dan@lkg.dec.com, bound@zk3.dec.com
Subject: (IPng 567) Re:  IPv6 fragments: can they overlap? 
In-Reply-To: Your message of "Tue, 22 Aug 1995 12:33:00 PDT."
             <9508221936.AA19002@mail1.digital.com> 
X-Mailer: exmh version 1.5omega 10/6/94
Date: Tue, 22 Aug 1995 16:15:19 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In  <9508221936.AA19002@mail1.digital.com> , Michael Stein wrote:

> Not allowing overlapping fragments has another implication:
> 
> Say I send a packet in fragments and then decide that it didn't
> make it and go to resend it.  If you don't allow overlapping
> fragments then since the destination can't tell which fragments
> were from the first try sending the packet and which were from
> the second I'm being required to re-fragment the original packet
> exactly the same way as the first time...

Resending requires you to choose a new identification longword
and so the fragments can't be confused.

Matt Thomas                          Internet:   thomas@lkg.dec.com
U*X Networking For OpenVMS           WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:41:48 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13821; Tue, 22 Aug 95 13:41:48 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13814; Tue, 22 Aug 95 13:41:39 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA17801; Tue, 22 Aug 1995 13:30:25 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id NAA15227; Tue, 22 Aug 1995 13:30:15 -0700
Received: from muggsy.lkg.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA26620; Tue, 22 Aug 1995 13:20:00 -0700
Received:  from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP
	id AA27139; Tue, 22 Aug 1995 16:19:55 -0400
Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.11/8.6.9) with SMTP id QAA19367; Tue, 22 Aug 1995 16:24:02 GMT
Message-Id: <199508221624.QAA19367@whydos.lkg.dec.com>
X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
To: Scott Bradner <sob@newdev.harvard.edu>
Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com, dan@lkg.dec.com
Subject: (IPng 568) Re:  IPv6 fragments: can they overlap? 
In-Reply-To: Your message of "Tue, 22 Aug 1995 15:32:33 -0400."
             <199508221932.PAA01096@newdev.harvard.edu> 
X-Mailer: exmh version 1.5omega 10/6/94
Date: Tue, 22 Aug 1995 16:24:02 +0000
From: Matt Thomas <matt@lkg.dec.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


In  <199508221932.PAA01096@newdev.harvard.edu> , Scott Bradner  wrote:

> Matt,
> 	Is there a way that one could do this and still deal with duplicated
> packets (fragments)?  Packet duplication is not all that uncommon in the net.

Oops.  Hmmm.

Assuming that the duplication will be relatively infrequent,
how about if there is overlapping data then the data carried
by the fragment must be identical to the corresponding data
already received.

This is expensive (since it involves a potentially large data
comparision) but it will hopefully be an infrequent occurance.

I'm open to better solutions ...

Matt Thomas                          Internet:   thomas@lkg.dec.com
U*X Networking for OpenVMS           WWW URL:    http://ftp.dec.com/%7Ethomas/
Digital Equipment Corporation        Disclaimer: This message reflects my
Littleton, MA                                    own warped views, etc.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:52:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13888; Tue, 22 Aug 95 13:52:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13882; Tue, 22 Aug 95 13:52:27 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19276; Tue, 22 Aug 1995 13:41:15 -0700
Received: from mentat.com by mercury.Sun.COM (Sun.COM)
	id NAA17908; Tue, 22 Aug 1995 13:40:56 -0700
Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1)
	id AA16293; Tue, 22 Aug 95 13:39:06 PDT
Received: by feller.mentat.com (5.x/SMI-SVR4)
	id AA12287; Tue, 22 Aug 1995 13:40:25 -0700
Date: Tue, 22 Aug 1995 13:40:25 -0700
From: thartric@mentat.com (Tim Hartrick)
Message-Id: <9508222040.AA12287@feller.mentat.com>
To: ipng@sunroof2.Eng.Sun.COM
Subject: (IPng 569) Re:  One more thing about overlapping fragments
X-Sun-Charset: US-ASCII
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk



danmcd@cs.nrl.navy.mil wrote:

> 
> One more thing, reassembly should be done before ANY OTHER options are
> exercised, even hop-by-hop options which come before the fragment header.
> Why?  Well, consider a packet that was authenticated.  The authentication
> header comes AFTER fragmentation in the order of headers; this means that
> authentication will only happen after reassembly.
> 

Since hop-by-hop option headers as well as routing headers may be
modified by intermediate nodes how does the authentication checksum
calculation work?  Is there some compensation which occurs at the orig-
inating host to make the calculation on the destination host work
out correctly?  How does the originating host predict the final contents
of this hypothetical hop-by-hop option in order to make the authentication
checksum work out?


tim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:54:07 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13901; Tue, 22 Aug 95 13:54:07 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13841; Tue, 22 Aug 95 13:46:47 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA18467; Tue, 22 Aug 1995 13:35:28 -0700
Received: from frankenstein.piermont.com by venus.Sun.COM (Sun.COM)
	id NAA13150; Tue, 22 Aug 1995 13:35:24 -0700
Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id QAA05487; Tue, 22 Aug 1995 16:31:34 -0400
Message-Id: <199508222031.QAA05487@frankenstein.piermont.com>
X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol
To: Michael Stein <OSYSMAS@mvs.oac.ucla.edu>
Cc: Matt Thomas <matt@lkg.dec.com>, ipng@sunroof.Eng.Sun.COM, dan@lkg.dec.com,
        bound@zk3.dec.com
Subject: (IPng 570) Re: IPv6 fragments: can they overlap? 
In-Reply-To: Your message of "Tue, 22 Aug 1995 12:33:00 PDT."
             <199508221934.MAA00726@mercury.Sun.COM> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Tue, 22 Aug 1995 16:31:26 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Michael Stein writes:
> Not allowing overlapping fragments has another implication:
> 
> Say I send a packet in fragments and then decide that it didn't
> make it and go to resend it.

If you are sending a TCP frame over again,
its a "new packet" in the sense that it has a new ID -- ditto for
UDP applications that do their own retransmission. IP doesn't ever do
retransmission.

> If you don't allow overlapping fragments then since the destination
> can't tell which fragments were from the first try sending the
> packet and which were from the second I'm being required to
> re-fragment the original packet exactly the same way as the first
> time...

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:56:53 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13913; Tue, 22 Aug 95 13:56:53 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13907; Tue, 22 Aug 95 13:56:40 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19893; Tue, 22 Aug 1995 13:45:17 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id NAA18947; Tue, 22 Aug 1995 13:45:08 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id QAA01408; Tue, 22 Aug 1995 16:39:10 -0400 (EDT)
Date: Tue, 22 Aug 1995 16:39:10 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508222039.QAA01408@newdev.harvard.edu>
To: matt@lkg.dec.com, sob@newdev.harvard.edu
Subject: (IPng 571) Re:  IPv6 fragments: can they overlap?
Cc: bound@zk3.dec.com, dan@lkg.dec.com, ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Assuming that the duplication will be relatively infrequent

well, taking a quick look on my workstation (only up for a few hours)
I get 128 "completely duplicate packets" out of 3553 packets received.
not all that infrequent.

anyone else have real data on this?  (netstat -s works on my MachTen 
system)

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 13:58:52 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13925; Tue, 22 Aug 95 13:58:52 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13919; Tue, 22 Aug 95 13:58:39 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA20254; Tue, 22 Aug 1995 13:47:23 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id NAA19305; Tue, 22 Aug 1995 13:46:28 -0700
Subject: (IPng 572) Re: IPv6 fragments
To: Scott Bradner <sob@newdev.harvard.edu>
Date: Tue, 22 Aug 1995 16:45:50 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: danmcd@cs.nrl.navy.mil, ipng@sunroof2.Eng.Sun.COM
In-Reply-To: <199508222017.QAA01334@newdev.harvard.edu> from "Scott Bradner" at Aug 22, 95 04:17:41 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508222145.aa21828@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> just to be clear, the fragment that comes in which would overlap with
> a fragment already received is discarded.

Yes.  That's how our code does it.

> the 1st letter in this thread seemed to say that the packet being
> reassembled might be tossed &/or a warning message be generated - that
> seemed to be a bit of a problem in the real world - did I misread?

We don't generate warning messages for overlapping packets, nor toss what we
have so-far reassembled.  Overlaps or duplicate fragments are silently
discarded.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 14:01:34 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13937; Tue, 22 Aug 95 14:01:34 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13931; Tue, 22 Aug 95 14:01:21 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA20762; Tue, 22 Aug 1995 13:50:09 -0700
Received: from lobster.wellfleet.com by mercury.Sun.COM (Sun.COM)
	id NAA20166; Tue, 22 Aug 1995 13:48:50 -0700
Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
	id AA10541; Tue, 22 Aug 95 16:47:16 EDT
Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1)
	id AA20348; Tue, 22 Aug 95 16:48:28 EDT
Date: Tue, 22 Aug 95 16:48:28 EDT
From: dhaskin@BayNetworks.com (Dimitry Haskin)
Message-Id: <9508222048.AA20348@BayNetworks.com>
To: matt@lkg.dec.com
Subject: (IPng 573) Re: IPv6 fragments: can they overlap?
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


> From major@marvin Tue Aug 22 16:34:59 1995
> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol
> To: Scott Bradner <sob@newdev.harvard.edu>
> Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com, dan@lkg.dec.com
> Subject: (IPng 568) Re:  IPv6 fragments: can they overlap? 
> X-Mailer: exmh version 1.5omega 10/6/94
> Date: Tue, 22 Aug 1995 16:24:02 +0000
> From: Matt Thomas <matt@lkg.dec.com>
> Sender: owner-ipv6@marvin
> Content-Length: 1202
> 
> 
> In  <199508221932.PAA01096@newdev.harvard.edu> , Scott Bradner  wrote:
> 
> > Matt,
> > 	Is there a way that one could do this and still deal with duplicated
> > packets (fragments)?  Packet duplication is not all that uncommon in the net.
> 
> Oops.  Hmmm.
> 
> Assuming that the duplication will be relatively infrequent,
> how about if there is overlapping data then the data carried
> by the fragment must be identical to the corresponding data
> already received.
> 
> This is expensive (since it involves a potentially large data
> comparision) but it will hopefully be an infrequent occurance.
> 
> I'm open to better solutions ...
> 

Matt,

I believe that just discarding duplicate/overlapping fragments (except
the very first one) is sufficient to guard against the attack you worry
about.  The problem was due to the re-assembly code that would just replace
an already received fragment with a newly arrived overlapping fragment.
This should be no-no.

Dimitry
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 14:15:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14008; Tue, 22 Aug 95 14:15:45 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA13943; Tue, 22 Aug 95 14:07:15 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21662; Tue, 22 Aug 1995 13:56:01 -0700
Received: from timbuk.cray.com by mercury.Sun.COM (Sun.COM)
	id NAA22107; Tue, 22 Aug 1995 13:55:50 -0700
Received: from frenzy.cray.com (frenzy.cray.com [128.162.84.21]) by timbuk.cray.com (8.6.12/CRI-8-1.16) with SMTP id PAA00235 for <ipng@sunroof.eng.sun.com>; Tue, 22 Aug 1995 15:55:41 -0500
Received: by frenzy.cray.com
	id AA03058; 4.1/CRI-5.6; Tue, 22 Aug 95 15:55:48 CDT
Date: Tue, 22 Aug 95 15:55:48 CDT
From: dab@berserkly.cray.com (David A. Borman)
Message-Id: <9508222055.AA03058@frenzy.cray.com>
To: ipng@sunroof.Eng.Sun.COM, matt@lkg.dec.com
Subject: (IPng 574) Re:  IPv6 fragments: can they overlap?
Cc: bound@zk3.dec.com, dan@lkg.dec.com
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Matt Thomas writes:

> Yesterday on one of the FreeBSD/NetBSD/BSDI mailing lists (they all seem
> to merge together after a while), there was a discussion about IP firewalls
> and the use of overlapping fragments to maliciously tunnel through them.
> 
> The technique was that the first fragment contains a valid/allowed transport
> header (and thus is allowed through the firewall), then a following fragment
> (which is given a free ride since its header has been allowed through)
> overlays that header with a new header which would not be otherwise allowed
> by the firewall.  When the packet is reassembled at the destination, the
> packet is delivered to some user other than what than was specified in the
> original fragment (instead of port 53 for BIND, port ??? for whatever 
> nefarious reason).
....
> Could we add something like the following to the fragmentation section:
> 
> "As the payload is divided into fragments, each fragment must contain a
> discrete portion of the payload.  Upon reassembly, if the contents of a
> fragment overlaps that of an already processed fragment then that 
> fragment option should be considered in error and an Parameter Problem ICMP
> message shouldbe  sent".

You don't need to disallow overlapping fragments to solve this security
issue.  You just add the rule to the reassmebly code that if an incoming
fragment overlaps an already received fragment, you trim the overlapping
parts from the incoming fragment before you reassemble it.  So, this
security issue is not a reason for disallowing overlapping fragments.

> In addition, not having to worry about overlapping fragments will permit
> simpler reassembly code in most implementations.

This, on the other hand, could be used as a reasonable technical reason
for disallowing overlapping fragments.

			-David Borman, dab@cray.com

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 14:53:47 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14115; Tue, 22 Aug 95 14:53:47 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14099; Tue, 22 Aug 95 14:49:30 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA29316; Tue, 22 Aug 1995 14:37:52 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id OAA02214; Tue, 22 Aug 1995 14:37:43 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HUDPGSTQDC0019GO@FNAL.FNAL.GOV>; Tue, 22 Aug 1995 16:36:51 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA08118; Tue, 22 Aug 95 16:36:07 CDT
Date: Tue, 22 Aug 1995 16:36:06 -0500
From: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Subject: (IPng 575) Re:  IPv6 fragments: can they overlap?
In-Reply-To: Your message of Tue,
 22 Aug 95 15:01:42 -0100. <199508221501.PAA18769@whydos.lkg.dec.com>
To: Matt Thomas <matt@lkg.dec.com>
Cc: ipng@sunroof.Eng.Sun.COM, dan@lkg.dec.com, bound@zk3.dec.com
Message-Id: <9508222136.AA08118@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
X-Face: 
 /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{<k&QF?d6L7o&zLqb%kXn!!]ykXMKtTiy9#20]$EKP/^Z$T]'P6,
 8L#r&mH4PB<ljN,_.=iCpv#N:HIcy5t7{HV:<=g=V?^;-d,J*xkq0r
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Could we add something like the following to the fragmentation section:
> 
> "[...]  Upon reassembly, if the contents of a
> fragment overlaps that of an already processed fragment then that 
> fragment option should be considered in error and an Parameter Problem ICMP
> message shouldbe  sent".

In IPv4 you couldn't impose this condition because a packet could be
duplicated, then the two copies could be fragmented differently by
routers.  Routers don't fragment forwarded IPv6 packets, but a
fragment could still be duplicated.  I don't think the extra hair to
distinguish a duplicated fragment from an overlapping fragment will
pay off in security.

I should think that the implementation, being free to keep the last
or the first copy of duplicated data, is also free to compare the two
and discard the whole packet if there's a mismatch.  That seems like
a more robust defense.

And besides, packet level authentication will make it moot, won't it?
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 14:59:02 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14155; Tue, 22 Aug 95 14:59:02 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14149; Tue, 22 Aug 95 14:58:54 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA01153; Tue, 22 Aug 1995 14:47:34 -0700
Received: from auspex-gw.auspex.com by venus.Sun.COM (Sun.COM)
	id OAA16199; Tue, 22 Aug 1995 14:47:25 -0700
Received: from auspex.Auspex.com (auspex-e6.auspex.com [144.48.8.10]) by auspex-gw.auspex.com (8.6.12/8.6.12) with SMTP id OAA11515; Tue, 22 Aug 1995 14:43:24 -0700
Received: from coastsider.auspex.com by auspex.Auspex.com (4.1/SMI-4.1)
	id AA05218; Tue, 22 Aug 95 14:43:23 PDT
Date: Tue, 22 Aug 95 14:43:23 PDT
From: wayne@auspex.com (Wayne Hathaway)
Message-Id: <9508222143.AA05218@auspex.Auspex.com>
To: dab@berserkly.cray.com, ipng@sunroof.Eng.Sun.COM, matt@lkg.dec.com
Subject: (IPng 576) Re: IPv6 fragments: can they overlap?
Cc: bound@zk3.dec.com, dan@lkg.dec.com
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> You don't need to disallow overlapping fragments to solve this
> security issue.  You just add the rule to the reassmebly code
> that if an incoming fragment overlaps an already received
> fragment, you trim the overlapping parts from the incoming
> fragment before you reassemble it.

Doesn't this assume the fragments arrive in order?  It wouldn't
seem that hard to use some routing options or something to slow
down the first fragment (once it has passed the firewall) so that
the second arrives first, in which case the authenticated part of
the first fragment header would be discarded in favor of the
already-there nefarious second fragment.  No?

    Wayne Hathaway              Internet: wayne@auspex.com
    Auspex Systems                 Phone: 408-986-2044
    5200 Great America Parkway       FAX: 408-986-2020
    Santa Clara, CA 95054
    NOTE: Opinions are the author's, NOT those of Auspex!
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 15:50:31 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14230; Tue, 22 Aug 95 15:50:31 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14224; Tue, 22 Aug 95 15:50:17 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA10262; Tue, 22 Aug 1995 15:39:01 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id PAA15338; Tue, 22 Aug 1995 15:38:58 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa22341;
          22 Aug 95 23:37 GMT
To: Wayne Hathaway <wayne@auspex.com>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 577) Re: IPv6 fragments: can they overlap? 
In-Reply-To: Your message of "Tue, 22 Aug 1995 14:43:23 PDT."
             <9508222143.AA05218@auspex.Auspex.com> 
Date: Tue, 22 Aug 1995 18:37:07 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508222337.aa22341@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <9508222143.AA05218@auspex.Auspex.com>, Wayne Hathaway writes:
>> You don't need to disallow overlapping fragments to solve this
>> security issue.  You just add the rule to the reassmebly code
>> that if an incoming fragment overlaps an already received
>> fragment, you trim the overlapping parts from the incoming
>> fragment before you reassemble it.
>
>Doesn't this assume the fragments arrive in order?  It wouldn't
>seem that hard to use some routing options or something to slow
>down the first fragment (once it has passed the firewall) so that
>the second arrives first, in which case the authenticated part of
>the first fragment header would be discarded in favor of the
>already-there nefarious second fragment.  No?

	I think these issues have already been decided and then rehashed
several times on the IPsec lists. The bottom line is that doing fragmentation
after authentication opens you up to new denial-of-service attacks.
Since we can't do much about denial-of-service attacks in general, however,
it isn't that big of a loss. The real solution to this problem is to use
path MTUs properly and avoid fragmentation in the first place.

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 16:01:13 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14242; Tue, 22 Aug 95 16:01:13 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14236; Tue, 22 Aug 95 16:01:00 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA12382; Tue, 22 Aug 1995 15:49:31 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id PAA17713; Tue, 22 Aug 1995 15:49:03 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa22404;
          22 Aug 95 23:47 GMT
To: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 578) Re:  One more thing about overlapping fragments 
In-Reply-To: Your message of "Tue, 22 Aug 1995 16:08:02 EST."
             <9508222108.aa21465@cs.nrl.navy.mil> 
Date: Tue, 22 Aug 1995 18:47:39 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508222347.aa22404@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <9508222108.aa21465@cs.nrl.navy.mil>, Dan McDonald writes:
>Our reassembly code drops fragments that cause overlap, plain and simple.

	Yep. As should everyone, IMO.

>One more thing, reassembly should be done before ANY OTHER options are
>exercised, even hop-by-hop options which come before the fragment header.

	I disagree.

>Why?  Well, consider a packet that was authenticated.  The authentication
>header comes AFTER fragmentation in the order of headers; this means that
>authentication will only happen after reassembly.
>
>Although no such hop-by-hop option exists yet, I'd imagine that someday
>there might be one that I don't want to have executed at my endpoint until I
>know that packet is authentic.  (Not to mention, if my datagram is chopped
>into 2 pieces, my end system processes two copies of the hop-by-hop options
>for the same datagram. :)

	My recollection of IPv4 reassembly is that the destination host ONLY
processes options for the fragment at offset zero. If this carries over into
IPv6, which I believe it should, the chain of optional headers before the
fragmentation header is only processed by the destination host for fragments
with an offset of zero, and those in all other chains are ignored. This
requires that reassembly be done before processing of optional headers.

>Otherwise, we may see fragmentation-based attacks on IPv6 systems, because
>we don't authenticate fragmented datagrams; we only do end-to-end
>authentication!

	Keep in mind, though, that the only attacks that should be feasable
on the reassembly engine are denial-of-service attacks, and IPsec really isn't
able to defend against those more than to let you know that some forms of them
are taking place. I had thought that the fragmentation denial-of-service
attack on IPsec issue had been discussed a few times on the IPsec lists. We
really can't defend against most denial-of-service attacks, so this
isn't such a big problem. And, of course, fragmentation should be
avoided anyway, in which case this is all moot.

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 16:05:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14258; Tue, 22 Aug 95 16:05:45 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14252; Tue, 22 Aug 95 16:05:32 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13367; Tue, 22 Aug 1995 15:54:19 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id PAA18546; Tue, 22 Aug 1995 15:54:07 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa22416;
          22 Aug 95 23:49 GMT
To: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 579) Re:  One more thing about overlapping fragments 
In-Reply-To: Your message of "Tue, 22 Aug 1995 16:08:02 EST."
             <9508222108.aa21465@cs.nrl.navy.mil> 
Date: Tue, 22 Aug 1995 18:49:47 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508222349.aa22416@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <9508222108.aa21465@cs.nrl.navy.mil>, Dan McDonald writes:
>I should've read Matt's note more closely, I forgot to address one thing.

	It looks like I got egg on my face, too.

>One more thing, reassembly should be done before ANY OTHER options are
>exercised, even hop-by-hop options which come before the fragment header.

	I think we actually are saying the same thing here; mea culpa for
the confusion in my last note.

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 17:14:05 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14380; Tue, 22 Aug 95 17:14:05 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14374; Tue, 22 Aug 95 17:13:52 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA22846; Tue, 22 Aug 1995 17:02:39 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id RAA01002; Tue, 22 Aug 1995 17:02:38 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id UAA02021; Tue, 22 Aug 1995 20:02:50 -0400 (EDT)
Date: Tue, 22 Aug 1995 20:02:50 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508230002.UAA02021@newdev.harvard.edu>
To: cmetz@sundance.itd.nrl.navy.mil, danmcd@cs.nrl.navy.mil
Subject: (IPng 580) Re: One more thing about overlapping fragments
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> If this carries over into
> IPv6, which I believe it should, the chain of optional headers before the
> fragmentation header is only processed by the destination host for fragments
> with an offset of zero, and those in all other chains are ignored. This
> requires that reassembly be done before processing of optional headers.

assuming that all the options can fit in the first fragment

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 22 20:07:49 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14478; Tue, 22 Aug 95 20:07:49 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14472; Tue, 22 Aug 95 20:07:40 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA08557; Tue, 22 Aug 1995 19:56:27 -0700
Received: from mail1.digital.com by venus.Sun.COM (Sun.COM)
	id TAA26175; Tue, 22 Aug 1995 19:56:28 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA27036; Tue, 22 Aug 1995 19:49:21 -0700
Received: by xirtlu.zk3.dec.com; id AA10563; Tue, 22 Aug 1995 22:49:18 -0400
Message-Id: <9508230249.AA10563@xirtlu.zk3.dec.com>
To: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Cc: Wayne Hathaway <wayne@auspex.com>, ipng@sunroof.Eng.Sun.COM
Subject: (IPng 581) Re: IPv6 fragments: can they overlap? 
In-Reply-To: Your message of "Tue, 22 Aug 95 18:37:07 CDT."
             <9508222337.aa22341@cs.nrl.navy.mil> 
Date: Tue, 22 Aug 95 22:49:12 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>Since we can't do much about denial-of-service attacks in general, however,
>it isn't that big of a loss. The real solution to this problem is to use
>path MTUs properly and avoid fragmentation in the first place.

Exactly.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 06:36:31 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14608; Wed, 23 Aug 95 06:36:31 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14602; Wed, 23 Aug 95 06:36:18 PDT
Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06344; Wed, 23 Aug 1995 06:25:06 -0700
Received: from lobster.wellfleet.com by Sun.COM (sun-barr.Sun.COM)
	id AA22249; Wed, 23 Aug 95 06:25:06 PDT
Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
	id AA17059; Wed, 23 Aug 95 09:22:32 EDT
Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1)
	id AA17954; Wed, 23 Aug 95 09:23:38 EDT
Date: Wed, 23 Aug 95 09:23:38 EDT
Message-Id: <9508231323.AA17954@BayNetworks.com>
Received: by karma.engeast (4.1/SMI-4.1)
	id AA05574; Wed, 23 Aug 95 09:23:26 EDT
From: Mike Davis <mdavis@BayNetworks.com>
To: matt@lkg.dec.com
Cc: sob@newdev.harvard.edu, ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com,
        dan@lkg.dec.com
In-Reply-To: <199508221624.QAA19367@whydos.lkg.dec.com> (message from Matt
	Thomas on Tue, 22 Aug 1995 16:24:02 +0000)
Subject: (IPng 582) Re: IPv6 fragments: can they overlap?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

[Scott Bradner wonders how to deal with the not uncommon case of
duplicated fragments.  Matt Thomas suggests a data compare]


Hi All,

The original note in this thread suggested that the motivation for
rejecting overlapping fragments is security.  In all the ensuing
discussion I don't think I have seen any argument against the
following approach:  If a fragment comes in that overlaps an existing
fragment, extract only the new octets.  This will prevent the
insidious fragment from changing the port at a firewall, will drop
duplicates harmlessly, and save the cost of the compare.
Equivilantly, the fragments can be blindly reassembled in the reverse
order from which they are recieved.

I don't know what the cost/benefit ratio of this approach is, but I
offer it for discussion.

--mad



Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 07:03:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14621; Wed, 23 Aug 95 07:03:45 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14615; Wed, 23 Aug 95 07:03:32 PDT
Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AB08172; Wed, 23 Aug 1995 06:52:16 -0700
Received: from lobster.wellfleet.com by venus.Sun.COM (Sun.COM)
	id GAA17655; Wed, 23 Aug 1995 06:52:12 -0700
Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
	id AA19676; Wed, 23 Aug 95 09:50:51 EDT
Received: from karma.engeast by BayNetworks.com (4.1/SMI-4.1)
	id AA19306; Wed, 23 Aug 95 09:52:04 EDT
Date: Wed, 23 Aug 95 09:52:04 EDT
Message-Id: <9508231352.AA19306@BayNetworks.com>
Received: by karma.engeast (4.1/SMI-4.1)
	id AA05577; Wed, 23 Aug 95 09:51:49 EDT
From: Mike Davis <mdavis@BayNetworks.com>
To: wayne@auspex.com
Cc: dab@berserkly.cray.com, ipng@sunroof.Eng.Sun.COM, matt@lkg.dec.com,
        bound@zk3.dec.com, dan@lkg.dec.com
In-Reply-To: <9508222143.AA05218@auspex.Auspex.com> (wayne@auspex.com)
Subject: (IPng 583) Re: IPv6 fragments: can they overlap?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

   Date: Tue, 22 Aug 95 14:43:23 PDT
   From: wayne@auspex.com (Wayne Hathaway)
   Cc: bound@zk3.dec.com, dan@lkg.dec.com
   Sender: owner-ipng@sunroof.Eng.Sun.COM
   Precedence: bulk

   > You don't need to disallow overlapping fragments to solve this
   > security issue.  You just add the rule to the reassmebly code
   > that if an incoming fragment overlaps an already received
   > fragment, you trim the overlapping parts from the incoming
   > fragment before you reassemble it.

   Doesn't this assume the fragments arrive in order?  It wouldn't
   seem that hard to use some routing options or something to slow
   down the first fragment (once it has passed the firewall) so that
   the second arrives first, in which case the authenticated part of
   the first fragment header would be discarded in favor of the
   already-there nefarious second fragment.  No?

In terms of the original note in this thread, you are positing that
the fragment with the bogus data (protocol port, etc) comes first, the
"Trojan horse" comes later.  I don't think this is a problem.  Upon
reassembly, the bogus data is in place.  The firewall does whatever
authentication it does on a packet.  The packet is exposed and
rejected.

There might be other reasons to reject the scheme in question,
though. The point was made that all fragments are created by the
originator, who presumably has no [legitimate] reason to create
overlapping fragments.  As an engineering choice I might decide that
the probablility of legitimate overlapping (as opposed to pure
duplicated) fragments is small enough that the cost of the code to
detect this is greater than the eventual benefit of "be liberal in
what you receive. . ."  Personally, I'd go with the more liberal
approach, but that's just my opinion.

--mad


Mike Davis == mdavis@pobox.wellfleet.com == +1 508 436 8016
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 10:26:39 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14778; Wed, 23 Aug 95 10:26:39 PDT
Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14772; Wed, 23 Aug 95 10:26:29 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id KAA14402; Wed, 23 Aug 1995 10:15:16 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id KAA24208; Wed, 23 Aug 1995 10:14:51 -0700
Date: Wed, 23 Aug 1995 10:14:51 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508231714.KAA24208@bobo.Eng.Sun.COM>
To: matt@lkg.dec.com
Subject: (IPng 584) Re: IPv6 fragments: can they overlap?
Cc: 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


> Assuming that the duplication will be relatively infrequent,
> how about if there is overlapping data then the data carried
> by the fragment must be identical to the corresponding data
> already received.
> 
> This is expensive (since it involves a potentially large data
> comparision) but it will hopefully be an infrequent occurance.

I think you can avoid such complication by distringuishing between
complete duplicates and partial duplicates.

If you receive a complete duplicate (i.e. the reassembly buffer
contains all of the fragment) you can simply drop the packet. Complete
duplicates are caused by packet duplication in the network.

If you receive a partial duplicate (i.e. where some parts of the fragment
have already been received) it would be ok to drop the packet and
possibly send an ICMP error. Partial duplicates can not be caused by 
packet duplication since routers do not (re)fragment packets.

   Erik

BTW: On a Solaris 2.X system netstat -s will show ipReasmDuplicates
and ipReasmPartDups separate. I've never seen any partial duplicates.
Probably because it requires packet duplication along paths with different
MTU and MTU discovery turned off.



 
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 10:49:57 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14805; Wed, 23 Aug 95 10:49:57 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14639; Wed, 23 Aug 95 08:51:24 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AB17268; Wed, 23 Aug 1995 08:40:09 -0700
Received: from timbuk.cray.com by mercury.Sun.COM (Sun.COM)
	id IAA14607; Wed, 23 Aug 1995 08:40:07 -0700
Received: from frenzy.cray.com (frenzy.cray.com [128.162.84.21]) by timbuk.cray.com (8.6.12/CRI-8-1.16) with SMTP id KAA25965 for <ipng@sunroof.eng.sun.com>; Wed, 23 Aug 1995 10:40:05 -0500
Received: by frenzy.cray.com
	id AA03457; 4.1/CRI-5.6; Wed, 23 Aug 95 10:40:13 CDT
Date: Wed, 23 Aug 95 10:40:13 CDT
From: dab@berserkly.cray.com (David A. Borman)
Message-Id: <9508231540.AA03457@frenzy.cray.com>
To: cmetz@sundance.itd.nrl.navy.mil
Subject: (IPng 585) Re: IPv6 fragments: can they overlap?
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> it isn't that big of a loss. The real solution to this problem is to use
> path MTUs properly and avoid fragmentation in the first place.

Path MTUs work great for allowing TCP to avoid IP fragmentation, but
it doesn't help much with large UDP packets.

			-David Borman, dab@cray.com

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 11:36:42 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14904; Wed, 23 Aug 95 11:36:42 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14885; Wed, 23 Aug 95 11:28:03 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA10352; Wed, 23 Aug 1995 11:16:50 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id LAA08118; Wed, 23 Aug 1995 11:16:48 -0700
Subject: (IPng 586) Re:  IPv6 fragments: can they overlap?
To: dab@berserkly.cray.com, IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Date: Wed, 23 Aug 1995 14:16:52 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: Dan McDonald <danmcd@sundance.itd.nrl.navy.mil>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508231916.aa14610@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> > it isn't that big of a loss. The real solution to this problem is to use
> > path MTUs properly and avoid fragmentation in the first place.
> 
> Path MTUs work great for allowing TCP to avoid IP fragmentation, but
> it doesn't help much with large UDP packets.

I have a question, by "doesn't help much" do you mean that path MTU cannot
be used with UDP, or do you mean that when sending large UDP packets, you're
going to drop some because Path MTU discovery might not have kicked in yet.
If the latter, ignore the rest of this note.

If the former, I beg to differ.  I quote RFC 1191:

   The obvious place to store this association is as a field in the
   routing table entries.  A host will not have a route for every
   possible destination, but it should be able to cache a per-host route
   for every active destination.  (This requirement is already imposed
   by the need to process ICMP Redirect messages.)

Dan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 11:59:55 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14931; Wed, 23 Aug 95 11:59:55 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA14925; Wed, 23 Aug 95 11:59:43 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14894; Wed, 23 Aug 1995 11:48:07 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id LAA17328; Wed, 23 Aug 1995 11:47:25 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HUEXTQFMSG001MPW@FNAL.FNAL.GOV>; Wed, 23 Aug 1995 13:47:09 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA11984; Wed, 23 Aug 95 13:46:20 CDT
Date: Wed, 23 Aug 1995 13:46:20 -0500
From: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Subject: (IPng 587) Re: IPv6 fragments: can they overlap?
In-Reply-To: Your message of Wed,
 23 Aug 95 10:14:51 PDT. <199508231714.KAA24208@bobo.Eng.Sun.COM>
To: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark)
Cc: matt@lkg.dec.com, ipng@sunroof.Eng.Sun.COM
Message-Id: <9508231846.AA11984@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> If you receive a complete duplicate (i.e. the reassembly buffer
> contains all of the fragment) you can simply drop the packet.

You mean drop the fragment?

> I've never seen any partial duplicates.  Probably because it
> requires packet duplication along paths with different MTU and MTU
> discovery turned off.

You don't need different MTUs.  Even if all links have MTU=1500, your
router might choose to break a 2000 byte packet into 1500 + 520,
while mine might choose 1016 + 1004.

But I'm puzzled as to why this comes up in the context of cracking
through firewalls.  If fragment offset > 0, the fragment can't modify
the TCP or UDP port numbers.  OK, it can change the TCP flags, so a
filter based on the setting of the TCP ACK bit could be thwarted, but
what would such a filter do if the first fragment had data length=8?
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 13:33:11 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15029; Wed, 23 Aug 95 13:33:11 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15023; Wed, 23 Aug 95 13:32:57 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA27451; Wed, 23 Aug 1995 13:21:44 -0700
Received: from fnal.fnal.gov by mercury.Sun.COM (Sun.COM)
	id NAA12338; Wed, 23 Aug 1995 13:21:29 -0700
Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.3-12 #3998)
 id <01HUF14F4SM8001N6P@FNAL.FNAL.GOV>; Wed, 23 Aug 1995 15:21:16 -0500 (CDT)
Received: from localhost.fnal.gov by munin.fnal.gov (4.1/SMI-4.1-m)
 id AA12672; Wed, 23 Aug 95 15:20:30 CDT
Date: Wed, 23 Aug 1995 15:20:29 -0500
From: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Subject: (IPng 588) Re: IPv6 fragments: can they overlap?
In-Reply-To: Your message of Wed,
 23 Aug 95 09:23:38 EDT. <9508231323.AA17954@BayNetworks.com>
To: Mike Davis <mdavis@BayNetworks.com>
Cc: sob@newdev.harvard.edu, ipng@sunroof.Eng.Sun.COM
Message-Id: <9508232020.AA12672@munin.fnal.gov>
Content-Transfer-Encoding: 7BIT
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> In all the ensuing discussion I don't think I have seen any
> argument against the following approach: If a fragment comes in
> that overlaps an existing fragment, extract only the new octets.

This is no solution.  There's no guarantee that the fragment that
reaches the firewall first will reach the destination node first.  In
fact, some have suggested that the odds can be tipped the other way
in IPv4 by including options in the offset=0 fragment.  If you're
relying on the order of arrival being preserved in IPv6, the bad guy
can at the very least repeat until lucky.

I claim the the only security-useful test the destination can perform
*on the fragments themselves* is to do a data compare in the case of
any overlap and reject the whole packet if there's a discrepancy.
Maybe this is expensive enough that you'd want an option to disable
it.
_________________________________________________________
Matt Crawford          crawdad@fnal.gov          Fermilab

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 13:35:14 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15044; Wed, 23 Aug 95 13:35:14 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15035; Wed, 23 Aug 95 13:34:59 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA27746; Wed, 23 Aug 1995 13:23:46 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id NAA12912; Wed, 23 Aug 1995 13:23:39 -0700
Subject: (IPng 589) There are no overlapping fragments in IPv6!!!
To: mdavis@pobox.wellfleet.com
Date: Wed, 23 Aug 1995 16:23:51 -0500 (EST)
From: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id:  <9508232123.aa23052@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Specifically because there is no intermediate fragmentation in IPv6.  If an
IPv6 datagram is retransmitted, it is done at the source, and at a layer
higher than IPv6, therefore the retransmitted IPv6 datagram will have a
different fragment identifier on its fragments.

We are all supposed to implement path MTU discovery at the hosts.  And
routers are supposed to send us "Message to big" ICMPv6 errors when my
datagram, or fragments are too large!  Fragmentation is only end-to-end,
which means duplicates may occur, but they will match, EXACTLY, what it was
duplicated from.

Dan
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 14:14:22 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15121; Wed, 23 Aug 95 14:14:22 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15115; Wed, 23 Aug 95 14:14:09 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03278; Wed, 23 Aug 1995 14:02:55 -0700
Received: from frankenstein.piermont.com by mercury.Sun.COM (Sun.COM)
	id OAA23370; Wed, 23 Aug 1995 14:02:34 -0700
Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id RAA11078; Wed, 23 Aug 1995 17:02:15 -0400
Message-Id: <199508232102.RAA11078@frankenstein.piermont.com>
X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol
To: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>
Subject: (IPng 590) Re:  There are no overlapping fragments in IPv6!!! 
In-Reply-To: Your message of "Wed, 23 Aug 1995 16:23:51 CDT."
             <9508232123.aa23052@cs.nrl.navy.mil> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Wed, 23 Aug 1995 17:01:53 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Dan McDonald writes:
> There are no overlapping fragments in IPv6!!! 

People should bear that in mind. Overlapping fragments in IPv6 are
*necessarily* bogus. Dan made this point very early on but people are
still talking about overlapping fragments as if there could be
legitimate reasons for overlap.

> Specifically because there is no intermediate fragmentation in IPv6.  If an
> IPv6 datagram is retransmitted, it is done at the source, and at a layer
> higher than IPv6, therefore the retransmitted IPv6 datagram will have a
> different fragment identifier on its fragments.

Perry
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 15:42:21 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15262; Wed, 23 Aug 95 15:42:21 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15256; Wed, 23 Aug 95 15:42:07 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15097; Wed, 23 Aug 1995 15:30:52 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id PAA17843; Wed, 23 Aug 1995 15:30:47 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa29692;
          23 Aug 95 23:27 GMT
To: Scott Bradner <sob@newdev.harvard.edu>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 591) Re: One more thing about overlapping fragments 
In-Reply-To: Your message of "Tue, 22 Aug 1995 20:02:50 -0400."
             <199508230002.UAA02021@newdev.harvard.edu> 
Date: Wed, 23 Aug 1995 18:27:09 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508232327.aa29692@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <199508230002.UAA02021@newdev.harvard.edu>, Scott Bradner writes:
>> If this carries over into
>> IPv6, which I believe it should, the chain of optional headers before the
>> fragmentation header is only processed by the destination host for fragments
>> with an offset of zero, and those in all other chains are ignored. This
>> requires that reassembly be done before processing of optional headers.
>
>assuming that all the options can fit in the first fragment

	This is predetermined by there being optional headers before the
fragmentation header. If you have too many pre-fragmentation optional headers
to construct a packet that fits within path MTU, I don't think you have any
really good options (you could tunnel, but that defeats the purpose since
those will be network control options).

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 15:47:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15275; Wed, 23 Aug 95 15:47:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15269; Wed, 23 Aug 95 15:47:23 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15803; Wed, 23 Aug 1995 15:36:09 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id PAA19367; Wed, 23 Aug 1995 15:35:57 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa00363;
          23 Aug 95 23:35 GMT
To: "David A. Borman" <dab@berserkly.cray.com>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 592) Re: IPv6 fragments: can they overlap? 
In-Reply-To: Your message of "Wed, 23 Aug 1995 10:40:13 CDT."
             <9508231540.AA03457@frenzy.cray.com> 
Date: Wed, 23 Aug 1995 18:35:17 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508232335.aa00363@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <9508231540.AA03457@frenzy.cray.com>, David A. Borman writes:
>> it isn't that big of a loss. The real solution to this problem is to use
>> path MTUs properly and avoid fragmentation in the first place.
>
>Path MTUs work great for allowing TCP to avoid IP fragmentation, but
>it doesn't help much with large UDP packets.

	UDP applications can still take a hint from path MTU as to how to
size their datagrams. This gets back into the previous discussion of
reassembly buffer sizes (and there's no sense in rehashing that one).

								-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 16:08:00 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15320; Wed, 23 Aug 95 16:08:00 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15314; Wed, 23 Aug 95 16:07:46 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA18488; Wed, 23 Aug 1995 15:56:31 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id PAA24708; Wed, 23 Aug 1995 15:56:27 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa01352;
          23 Aug 95 23:52 GMT
To: perry@piermont.com
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 593) Re: There are no overlapping fragments in IPv6!!! 
In-Reply-To: Your message of "Wed, 23 Aug 1995 17:01:53 -0400."
             <199508232102.RAA11078@frankenstein.piermont.com> 
Date: Wed, 23 Aug 1995 18:52:05 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508232352.aa01352@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <199508232102.RAA11078@frankenstein.piermont.com>, "Perry E. Metzger
" writes:
>Dan McDonald writes:
>> There are no overlapping fragments in IPv6!!! 
>
>People should bear that in mind. Overlapping fragments in IPv6 are
>*necessarily* bogus. Dan made this point very early on but people are
>still talking about overlapping fragments as if there could be
>legitimate reasons for overlap.

	IMO, the fragment that overlaps should be thrown away, but the
entire packet should not be. If an attacker tried to use an overlap for a
denial-of-service attack on the fragmentation engine, you *might* be able
to recover. Also, your reassembly timer will kill off the packet in a bit
anyway. This is best left as an implementation detail, though.

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 16:54:01 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15367; Wed, 23 Aug 95 16:54:01 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15361; Wed, 23 Aug 95 16:53:48 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA24227; Wed, 23 Aug 1995 16:42:35 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id QAA04582; Wed, 23 Aug 1995 16:42:33 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa04220;
          24 Aug 95 0:42 GMT
To: Alan Cox <iialan@iifeak.swan.ac.uk>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 594) Re: Two comments wrt drafts I sent 
In-Reply-To: Your message of "Tue, 22 Aug 1995 10:36:37 +0100."
             <m0skpl8-00013gC@iiit.swan.ac.uk> 
Date: Wed, 23 Aug 1995 19:42:23 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508240042.aa04220@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <m0skpl8-00013gC@iiit.swan.ac.uk>, Alan Cox writes:
>You are creating an alleged generic API with a missing piece. The implementati
>of a function to get the buffer length for an address family is sufficiently
>important and trivial that I feel it is needed. If you propose to change the
>hostname2addr() functions anyway this may no longer be an issue. All I propose
>is
>		size_t addrtonamesize(int af)
>		{
>			switch(af)
>			{
>				case AF_INET: return n;
>				case AF_INET6: return m;
>				case AF_AX25: return o;
>				case AF_IPX: return p;
>				default:
>					return -ENOCLUE; 8)
>			}
>		}

	I would suggest some thought be given to adding the POSIX sockets'
getaddrinfo() function to the IPv6 API spec. It solves this problem by
making the sockaddr more of the magic cookie it should have been in the
first place.

								-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 17:46:03 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15442; Wed, 23 Aug 95 17:46:03 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15436; Wed, 23 Aug 95 17:45:54 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA01493; Wed, 23 Aug 1995 17:34:40 -0700
Received: from noao.edu by mercury.Sun.COM (Sun.COM)
	id RAA13921; Wed, 23 Aug 1995 17:34:37 -0700
Received: from gemini.tuc.noao.edu by noao.edu (4.1/SAG-Noao.G102)
	id AA02177; Wed, 23 Aug 95 17:34:34 MST; for ipng@sunroof.eng.sun.com
Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14)
	id AA00847; Wed, 23 Aug 95 17:34:33 MST; for ipng@sunroof.eng.sun.com
Message-Id: <9508240034.AA00847@gemini.tuc.noao.edu>
From: rstevens@noao.edu (Richard Stevens)
Date: Wed, 23 Aug 1995 17:34:33 -0700
Reply-To: Richard Stevens <rstevens@noao.edu>
X-Phone: +1 520 297 9416
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>,
        Alan Cox <iialan@iifeak.swan.ac.uk>
Subject: (IPng 595) Re: Two comments wrt drafts I sent
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> 	I would suggest some thought be given to adding the POSIX sockets'
> getaddrinfo() function to the IPv6 API spec. It solves this problem by
> making the sockaddr more of the magic cookie it should have been in the
> first place.

It's been done: draft-sklower-ipv6-getconninfo-03.txt.

I printed the getaddrinfo() description from the latest Posix.1g draft,
and getconninfo() is almost identical, execept for names.  IPv6 should
just pick up the Posix function, assuming it's been done correctly.

	Rich Stevens
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 18:37:12 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15508; Wed, 23 Aug 95 18:37:12 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15502; Wed, 23 Aug 95 18:37:04 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA06223; Wed, 23 Aug 1995 18:25:50 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id SAA21328; Wed, 23 Aug 1995 18:25:51 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA00368; Wed, 23 Aug 1995 18:18:49 -0700
Received: by xirtlu.zk3.dec.com; id AA00899; Wed, 23 Aug 1995 21:18:47 -0400
Message-Id: <9508240118.AA00899@xirtlu.zk3.dec.com>
To: Richard Stevens <rstevens@noao.edu>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 596) Re: Two comments wrt drafts I sent 
In-Reply-To: Your message of "Wed, 23 Aug 95 17:34:33 PDT."
             <9508240034.AA00847@gemini.tuc.noao.edu> 
Date: Wed, 23 Aug 95 21:18:41 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>It's been done: draft-sklower-ipv6-getconninfo-03.txt.

>I printed the getaddrinfo() description from the latest Posix.1g draft,
>and getconninfo() is almost identical, execept for names.  IPv6 should
>just pick up the Posix function, assuming it's been done correctly.

Maybe for new applications not existing applications that you want to
port quickly.  getaddrinfo() will need the lower level API functions
too.  But, for a brand new application this might be nice.  

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 19:41:56 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15593; Wed, 23 Aug 95 19:41:56 PDT
Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15587; Wed, 23 Aug 95 19:41:47 PDT
Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id TAA14203; Wed, 23 Aug 1995 19:30:36 -0700
Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4)
	id AA07415; Wed, 23 Aug 1995 19:34:05 -0700
Date: Wed, 23 Aug 1995 19:34:05 -0700
From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan)
Message-Id: <9508240234.AA07415@kandinsky.Eng.Sun.COM>
To: ipng@sunroof
Subject: (IPng 597) re: Two comments wrt drafts I sent
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> From: "Alan Cox" <iialan@iiit.swan.ac.uk>
>
> > > In which case there should be a query maximum length function too so
> > > multiprotocol applications don't have to be telepathic.
> 
> > I would argue that this is outside the scope of the IPv6 API spec.  This
> > spec does specify how long the address buffer must be in order to store
> > the ascii representation of an IPv6 address.  So IPv6 applications have
> > all the information they need.
> 
> You are creating an alleged generic API with a missing piece. The implementation
> of a function to get the buffer length for an address family is sufficiently
> important and trivial that I feel it is needed. If you propose to change the
> hostname2addr() functions anyway this may no longer be an issue. All I propose
> is
> 		size_t addrtonamesize(int af)
> 		{
> 			switch(af)
> 			{
> 				case AF_INET: return n;
> 				case AF_INET6: return m;
> 				case AF_AX25: return o;
> 				case AF_IPX: return p;
> 				default:
> 					return -ENOCLUE; 8)
> 			}
> 		}
> 
> Be in libc somewhere. That makes a huge difference for applications that
> have to handle generic address formats, and removes hard coded assumptions 
> from programs. It also means you can now swap a shared library if a new IPv6
> address writing format came along which is longer than the current one and not
> break applications.

Our objectives in writing the IPv6 socket API spec were not so
ambitious as to lead us to attempting to fix all of the various
problems in the socket interface, such as its lack of transport
independence.  Our goal was to define the minimal set of *extensions*
to the existing socket interface to make it support IPv6.  Given that
the current socket interface has no function to determine the length
of a printable IPv4 address, we did not think it necessary to add one
for IPv6.  As pointed out below, Posix is adding transport independent
features to the socket interface.  I think we should let them worry
about these issues, while we concentrate on IPv6.  (We'll also have a
better chance of actually finishing this spec if we stick to IPv6
issues!)

> > From: "Richard Stevens" <rstevens@noao.edu>
> > 
> > 	I would suggest some thought be given to adding the POSIX sockets'
> > getaddrinfo() function to the IPv6 API spec. It solves this problem by
> > making the sockaddr more of the magic cookie it should have been in the
> > first place.
> 
> It's been done: draft-sklower-ipv6-getconninfo-03.txt.
> 
> I printed the getaddrinfo() description from the latest Posix.1g draft,
> and getconninfo() is almost identical, execept for names.  IPv6 should
> just pick up the Posix function, assuming it's been done correctly.

I don't think that we need to "adopt" this Posix function into the
IPv6 API spec.  Rather, we can just reference it.  There is no need
for us to "re-specify" things that Posix is already defining.  Note,
BTW, that we already do have a reference to Keith Sklower's
getconninfo internet-draft in our spec.

Bob.
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 20:04:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15614; Wed, 23 Aug 95 20:04:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15608; Wed, 23 Aug 95 20:04:22 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11354; Wed, 23 Aug 1995 19:53:05 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id TAA00445; Wed, 23 Aug 1995 19:53:06 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id WAA05578; Wed, 23 Aug 1995 22:53:15 -0400 (EDT)
Date: Wed, 23 Aug 1995 22:53:15 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508240253.WAA05578@newdev.harvard.edu>
To: perry@piermont.com
Subject: (IPng 598) Re: There are no overlapping fragments in IPv6!!!
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> Overlapping fragments in IPv6 are *necessarily* bogus.


I don't think that is true, duplicate fragments created by the normal
processes of the Internet are legit.  i.e. one should not assume that
an attack is underway just because you get a dup fragment.

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 20:18:17 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15634; Wed, 23 Aug 95 20:18:17 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15628; Wed, 23 Aug 95 20:18:09 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA11996; Wed, 23 Aug 1995 20:06:55 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id UAA01791; Wed, 23 Aug 1995 20:06:55 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA00121; Wed, 23 Aug 1995 19:51:32 -0700
Received: by xirtlu.zk3.dec.com; id AA02058; Wed, 23 Aug 1995 22:51:30 -0400
Message-Id: <9508240251.AA02058@xirtlu.zk3.dec.com>
To: Bob.Gilligan@Eng (Bob Gilligan)
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 599) Re: Two comments wrt drafts I sent 
In-Reply-To: Your message of "Wed, 23 Aug 95 19:34:05 PDT."
             <9508240234.AA07415@kandinsky.Eng.Sun.COM> 
Date: Wed, 23 Aug 95 22:51:24 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>I don't think that we need to "adopt" this Posix function into the
>IPv6 API spec.  Rather, we can just reference it.  There is no need
>for us to "re-specify" things that Posix is already defining.  Note,
>BTW, that we already do have a reference to Keith Sklower's
>getconninfo internet-draft in our spec.

100% behind Bob on this just to say it to the list.  We are, as Bob
pointed out, trying to define an API using BSD Sockets for IPv6.  We now
have several implementations completed and proof of concept for both the
sockets and dns apis.  We need to let POSIX, WINSOCKETS. X/open, and
SPEC 1170 do their thing with this API spec.  Its a starting point in
the industry not a finishing point.  Keiths API is very useful as a
multiprotocol API and a good services interface which, as Bob pointed
out, we reference.   Where it makes sense to change things we should and
changes are being done as we get input.  But trying to build what POSIX
et al do very well is a bit ambitious for this API spec IMHO.  Lets use
the KISS principle right now is my view and get some IPv6 apps ported
over an IPv6 aware stack and test what we have in there now.  For example
we have implemented the source route design in the API spec but to test
it we need an IPv6 router (at least two).  So we have to do the best we
can for now with what we can test.  

/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 20:52:17 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15651; Wed, 23 Aug 95 20:52:17 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15645; Wed, 23 Aug 95 20:52:09 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AB13577; Wed, 23 Aug 1995 20:40:56 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id UAA04552; Wed, 23 Aug 1995 20:40:57 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA17498; Wed, 23 Aug 1995 20:30:49 -0700
Received: by xirtlu.zk3.dec.com; id AA02527; Wed, 23 Aug 1995 23:30:48 -0400
Message-Id: <9508240330.AA02527@xirtlu.zk3.dec.com>
To: Scott Bradner <sob@newdev.harvard.edu>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 600) Re: There are no overlapping fragments in IPv6!!! 
In-Reply-To: Your message of "Wed, 23 Aug 95 22:53:15 EDT."
             <199508240253.WAA05578@newdev.harvard.edu> 
Date: Wed, 23 Aug 95 23:30:42 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>> Overlapping fragments in IPv6 are *necessarily* bogus.

>I don't think that is true, duplicate fragments created by the normal
>processes of the Internet are legit.  i.e. one should not assume that
>an attack is underway just because you get a dup fragment.

I agree with Scott and it makes sense to me too.

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 21:31:24 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15676; Wed, 23 Aug 95 21:31:24 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15670; Wed, 23 Aug 95 21:31:15 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15217; Wed, 23 Aug 1995 21:20:01 -0700
Received: from mail1.digital.com by mercury.Sun.COM (Sun.COM)
	id VAA07983; Wed, 23 Aug 1995 21:20:02 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA03513; Wed, 23 Aug 1995 21:07:19 -0700
Received: by xirtlu.zk3.dec.com; id AA02852; Thu, 24 Aug 1995 00:07:18 -0400
Message-Id: <9508240407.AA02852@xirtlu.zk3.dec.com>
To: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 601) Atlanta Interop 9/27-9/29 IPv6 Testing 
Date: Thu, 24 Aug 95 00:07:12 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

FYI from the implementors list.  Also Steve Deering is doing a full day
tutorial I see on IPv6 Wed 9/27.

/jim


Return-Path: owner-IPv6Imp@munnari.OZ.AU
Received: from decvax.zk3.dec.com by alpha.zk3.dec.com; (5.65v3.0/1.1.8.2/20May95-1022AM)
	id AA30619; Wed, 23 Aug 1995 23:35:40 -0400
Received: from murtoa.cs.mu.OZ.AU by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
	id AA11617; Wed, 23 Aug 1995 23:35:32 -0400
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0)
	id NAA03076; Thu, 24 Aug 1995 13:05:27 +1000
Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP
	id MAA03056; Thu, 24 Aug 1995 12:47:06 +1000
From: bound@zk3.dec.com
Received: from mail1.digital.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50)
	id AA26531; Thu, 24 Aug 1995 12:46:36 +1000 (from bound@zk3.dec.com)
Received: from xirtlu.zk3.dec.com by mail1.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA04701; Wed, 23 Aug 1995 19:37:11 -0700
Received: by xirtlu.zk3.dec.com; id AA01810; Wed, 23 Aug 1995 22:37:09 -0400
Message-Id: <9508240237.AA01810@xirtlu.zk3.dec.com>
To: IPv6Imp@munnari.OZ.AU
Cc: bound@zk3.dec.com
Subject: [IPv6Imp] Atlanta Interop 9/27-9/29 IPv6 Testing
Date: Wed, 23 Aug 95 22:37:03 -0400
X-Mts: smtp
Precedence: bulk

I am not 100% sure right now but we most likely will be at Interop (I think 
Jack Mccann and I) doing IPv6 again in the Digital booth.  I hope to
interoperate for sure with UNH booth depending on the shownet layout.
If our links have a router between us then only tunneling, unless the
router does IPv6 of course.

We will do what we did before: ping, ftp, and telnet.  On link and via
tunnels.

But also be prepared to handle these ND (May 95 Spec) functions:

  o  Router Solicitation and Advertisements.
  o  Neighbor Solicitation and Advertisements.

No redirects, validation, NUD, Proxy, or config value parameter
acceptence, and no extensions.  Trying to test the basics first.

I will have in the booth if possible an initial very basic prototype of 
DHCPv6 Server and Client (this will be based on the next spec when it comes 
out Sept 5th).  We need some proof of concept for this IETF work now.  Hope 
to also see work from INRIA and Competitive Automation on the next spec too
(not by Interop of course).  This will be a good test of the API spec
and better than ftp or telnet; using v6 for an application on a link
rather than hacking a toy v6 client/server application.

Node sipper will be back up for ping and ftp testing.  David Talleri at
Mitre has ftp client hack without LPRT and we will test it at sipper.
Jack Mccann or I will send mail when we have it reconfigured (we had to
replace the mama-board on the router) for testing.  We think we fixed
our ping checksum.  Need some work on both the ipv6 and icmpv6 specs for
checksums fyi.

So who else will be at Interop besides UNH?  Will we have a router at
Interop running IPv6?  

Can we all do the above ping, telnet, ftp and ND above?

thanks
/jim

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 23 22:22:40 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15697; Wed, 23 Aug 95 22:22:40 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15691; Wed, 23 Aug 95 22:22:27 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA17646; Wed, 23 Aug 1995 22:11:13 -0700
Received: from frankenstein.piermont.com by mercury.Sun.COM (Sun.COM)
	id WAA12639; Wed, 23 Aug 1995 22:11:13 -0700
Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id BAA11389; Thu, 24 Aug 1995 01:10:59 -0400
Message-Id: <199508240510.BAA11389@frankenstein.piermont.com>
X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol
To: Scott Bradner <sob@newdev.harvard.edu>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 602) Re: There are no overlapping fragments in IPv6!!! 
In-Reply-To: Your message of "Wed, 23 Aug 1995 22:53:15 EDT."
             <199508240253.WAA05578@newdev.harvard.edu> 
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 24 Aug 1995 01:10:47 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Scott Bradner writes:
> > Overlapping fragments in IPv6 are *necessarily* bogus.
> 
> I don't think that is true, duplicate fragments created by the normal
> processes of the Internet are legit.  i.e. one should not assume that
> an attack is underway just because you get a dup fragment.

*Duplicate* fragments are fine. *Overlapping* fragments, however,
can't occur except if something is wrong, because all fragmentation
occurs at the source. The normal mechanism for overlapping fragments
to occur in v4 is when duplicated packets get fragmented differently
at intermediate nodes (usually while taking differing paths). In v6
this can't happen, so only duplicated fragments are signs of normal
events.

This is not to say that overlapping fragments would necessarily
indicate an attack, but they do indicate that something is wrong
because they aren't "normal behavior". It thus seems fine to dictate
that in v6 overlapping frags are an error condition.

Perry
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 01:21:55 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15858; Thu, 24 Aug 95 01:21:55 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15852; Thu, 24 Aug 95 01:21:41 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA24928; Thu, 24 Aug 1995 01:10:29 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id BAA27312; Thu, 24 Aug 1995 01:10:24 -0700
Message-Id: <m0slXhp-00013gC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 603) Re: IPv6 fragments: can they overlap?
To: mdavis@BayNetworks.com (Mike Davis)
Date: Thu, 24 Aug 1995 09:32:09 +0100 (BST)
Cc: matt@lkg.dec.com, sob@newdev.harvard.edu, ipng@sunroof.Eng.Sun.COM,
        bound@zk3.dec.com, dan@lkg.dec.com
In-Reply-To: <9508231323.AA17954@BayNetworks.com> from "Mike Davis" at Aug 23, 95 09:23:38 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> The original note in this thread suggested that the motivation for
> rejecting overlapping fragments is security.  In all the ensuing
> discussion I don't think I have seen any argument against the
> following approach:  If a fragment comes in that overlaps an existing
> fragment, extract only the new octets.  This will prevent the
> insidious fragment from changing the port at a firewall, will drop
> duplicates harmlessly, and save the cost of the compare.
> Equivilantly, the fragments can be blindly reassembled in the reverse
> order from which they are recieved.

Fragments may not (and for Linux _will_ not) be sent in the order of first
fragment first packet. This is all a red herring. We have IP-AH , IP-ESP
and possibly SKIP coming in IPv6, the firewall is purely a red herring.

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 04:17:40 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15892; Thu, 24 Aug 95 04:17:40 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15886; Thu, 24 Aug 95 04:17:26 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA02540; Thu, 24 Aug 1995 04:06:11 -0700
Received: from newdev.harvard.edu by mercury.Sun.COM (Sun.COM)
	id EAA09803; Thu, 24 Aug 1995 04:06:05 -0700
Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id HAA06688; Thu, 24 Aug 1995 07:06:18 -0400 (EDT)
Date: Thu, 24 Aug 1995 07:06:18 -0400 (EDT)
From: Scott Bradner <sob@newdev.harvard.edu>
Message-Id: <199508241106.HAA06688@newdev.harvard.edu>
To: perry@piermont.com
Subject: (IPng 604) Re: There are no overlapping fragments in IPv6!!!
Cc: ipng@sunroof.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> *Duplicate* fragments are fine. *Overlapping* fragments, however ...


humm, I see "duplicate" as an example of "overlapping", do you think
that a specific test for "duplicate" be done, and if the fragment be a
"duplicate" then the fragment be silently discarded otherwise an error
should be reported?

Scott
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 07:35:57 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15966; Thu, 24 Aug 95 07:35:57 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA15960; Thu, 24 Aug 95 07:35:50 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA13700; Thu, 24 Aug 1995 07:24:36 -0700
Received: from jcdbs.itsi.disa.mil by mercury.Sun.COM (Sun.COM)
	id HAA00956; Thu, 24 Aug 1995 07:24:32 -0700
From: stelmacf@itsi.disa.mil
Received: from SMTPLink-Logicon.itsi.disa.mil (SMTPLink-Logicon.itsi.disa.mil [192.234.182.8]) by jcdbs.itsi.disa.mil (8.6.12/8.6.10) with SMTP id KAA16303 for <ipng@sunroof2.eng.sun.com>; Thu, 24 Aug 1995 10:23:50 -0400
Received: from cc:Mail by SMTPLink-Logicon.itsi.disa.mil
	id AA809284883; Wed, 23 Aug 95 22:08:12 EST
Date: Wed, 23 Aug 95 22:08:12 EST
Encoding: 4 Text
Message-Id: <9507248092.AA809284883@SMTPLink-Logicon.itsi.disa.mil>
To: ipng@sunroof2.Eng.Sun.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

     Please remove my name from your mailing lists
     
     
     My e-mail address is stelmacf@itsi.disa.mil

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 11:32:09 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16160; Thu, 24 Aug 95 11:32:09 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16154; Thu, 24 Aug 95 11:31:52 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA14053; Thu, 24 Aug 1995 11:20:34 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id LAA00129; Thu, 24 Aug 1995 11:20:34 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa06837;
          24 Aug 95 19:19 GMT
To: Richard Stevens <rstevens@noao.edu>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 605) Re: Two comments wrt drafts I sent 
In-Reply-To: Your message of "Wed, 23 Aug 1995 17:34:33 MST."
             <9508240034.AA00847@gemini.tuc.noao.edu> 
Date: Thu, 24 Aug 1995 14:18:59 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508241919.aa06837@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <9508240034.AA00847@gemini.tuc.noao.edu>, Richard Stevens writes:
>> 	I would suggest some thought be given to adding the POSIX sockets'
>> getaddrinfo() function to the IPv6 API spec. It solves this problem by
>> making the sockaddr more of the magic cookie it should have been in the
>> first place.
>
>It's been done: draft-sklower-ipv6-getconninfo-03.txt.
>
>I printed the getaddrinfo() description from the latest Posix.1g draft,
>and getconninfo() is almost identical, execept for names.  IPv6 should
>just pick up the Posix function, assuming it's been done correctly.

	We should probably then put getaddrinfo() into the IPv6 BSD API
spec as a required thing. We have the problem where, if the function is not
mandated, it won't always be available. If it isn't always available, it won't
be used, and it doesn't do us much good.

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 12:15:37 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16206; Thu, 24 Aug 95 12:15:37 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16200; Thu, 24 Aug 95 12:15:25 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21200; Thu, 24 Aug 1995 12:04:09 -0700
Received: from IETF.nri.reston.VA.US by mercury.Sun.COM (Sun.COM)
	id MAA10504; Thu, 24 Aug 1995 12:04:06 -0700
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15531;
          24 Aug 95 13:51 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;@mercury
Cc: ipng@sunroof.Eng.Sun.COM
From: Internet-Drafts@CNRI.Reston.VA.US
Reply-To: Internet-Drafts@CNRI.Reston.VA.US
Subject: (IPng 606) I-D ACTION:draft-ietf-ipngwg-nsap-ipv6-00.txt
Date: Thu, 24 Aug 95 13:51:21 -0400
Message-Id:  <9508241351.aa15531@IETF.CNRI.Reston.VA.US>
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     : OSI NSAPs and IPv6                                      
       Author(s) : J. Bound, B. Carpenter, D. Harrington, 
                   J. Houldsworth, A. Lloyd
       Filename  : draft-ietf-ipngwg-nsap-ipv6-00.txt
       Pages     : 17
       Date      : 08/23/1995

This document recommends that network implementors who have planned or 
deployed an OSI NSAP addressing plan, and who wish to deploy or transition 
to IPv6, should redesign a native IPv6 addressing plan to meet their needs.
However, it also defines a set of mechanisms for the support of OSI NSAP 
addressing in an IPv6 network.  These mechanisms are the ones that MUST be 
used if such support is required.  This document also defines a mapping of 
IPv6 addresses within the OSI address format, should this be required.     

Internet-Drafts are 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-nsap-ipv6-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-nsap-ipv6-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	
	                                                
     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)
	                                                
     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	
	                                                
     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	
	                                                
     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  mailserv@ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-ietf-ipngwg-nsap-ipv6-00.txt".
							
NOTE: The mail server at ds.internic.net 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.
							
For questions, please mail to Internet-Drafts@cnri.reston.va.us.
							

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@ds.internic.net"

Content-Type: text/plain
Content-ID: <19950824135018.I-D@CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-nsap-ipv6-00.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-ipngwg-nsap-ipv6-00.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19950824135018.I-D@CNRI.Reston.VA.US>

--OtherAccess--

--NextPart--

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 16:11:52 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16358; Thu, 24 Aug 95 16:11:52 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16352; Thu, 24 Aug 95 16:11:43 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA21910; Thu, 24 Aug 1995 16:00:28 -0700
Received: from dylan.mindspring.com by mercury.Sun.COM (Sun.COM)
	id QAA00524; Thu, 24 Aug 1995 16:00:25 -0700
Received: from sthomas.mindspring.com [168.121.37.118] by dylan.mindspring.com
	with SMTP id TAA11533 for <ipng@sunroof.eng.sun.com>; Thu, 24 Aug 1995 19:00:17 -0400
Message-Id: <199508242300.TAA11533@dylan.mindspring.com>
X-Sender: sthomas@mindspring.com
X-Mailer: Windows Eudora Version 2.1.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Aug 1995 18:44:53 -0400
To: ipng@sunroof.Eng.Sun.COM
From: Stephen Thomas <sthomas@mindspring.com>
Subject: (IPng 607) IPv6 over Token Ring
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


Gentle Readers:

For your viewing pleasure. (Five pages didn't seem to excessive,
so I've included the full text; if you'd prefer otherwise, let
me know and I won't do it again.) Please comment, etc.. I have
NOT sent this to the I-D repository.


Internet Engineering Task Force                           Stephen Thomas
INTERNET DRAFT                                               AT&T Tridom
<draft-ipngwg-token-ring-00.txt>                         August 24, 1995


 A Method for the Transmission of IPv6 Packets over Token Ring Networks



Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress."

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet Drafts
   Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US  West  Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.


Introduction

   This memo specifies the frame format for transmission of IPv6 [IPV6]
   packets and the method of forming IPv6 link-local addresses on Token
   Ring networks [8025]. It also specifies the content of the
   Source/Target Link-layer Address option used the the Router
   Solicitation, Router Advertisement, Neighbor Solicitation, and
   Neighbor Advertisement messages described in [DISC], when those
   messages are transmitted on a Token Ring.


IPv6 Encapsulation

   IPv6 packets are transmitted in LLC/SNAP frames, using long-format
   (48 bit) addresses.  The data field contains the IPv6 header and
   payload. The following figure shows a complete IPv6 frame.










Thomas                   Expires February 1996                  [Page 1]



INTERNET-DRAFT            IPv6 over Token Ring           August 24, 1995


                   +-------+-------+-------+-------+
                   |  SD   |  AC   |  FC   |       |
                   +-----------------------+       |
                   |      Destination Address      |
                   |       +-----------------------+
                   |       |     Source            |
                   +-------+    Address    +-------+
                   |                       | DSAP  |
                   +-------+-------+-------+-------+
                   | SSAP  |  CTL  |      OUI      |
                   +-------+-------+-------+-------+
                   |  OUI  |   EtherType   |       |
                   +-------+---------------+       |
                   |                               |
                   ~  IPv6 header and payload...   ~
                   |                               |
                   +-------------------------------+
                   |              FCS              |
                   +-------+-------+---------------+
                   |  ED   |  FS   |
                   +-------+-------+

   In the presence of source route bridges, a routing information field
   (RIF) may appear immediately after the source address. A RIF is
   present in frames when the most signficant bit of the source address
   is set to one.


Token Ring Header Fields

   SD - Starting Delimiter

   AC - Access Control

   FC - Frame Control

   Destination Address - 48-bit IEEE address of destination station

   Source Address - 48-bit IEEE address of source station

   DSAP - Destination Service Access Point (for LLC/SNAP format, shall
          always contain the value 0xAA)

   SSAP - Source Service Access Point (for LLC/SNAP format, shall
          always contain the value 0xAA)

   CTL - Control Field (for Unnumbered Information, shall always
         contain the value 0x03)





Thomas                    Expires February 1996                 [Page 2]



INTERNET-DRAFT            IPv6 over Token Ring           August 24, 1995


   OUI - Organizationally Unique Identifier (for EtherType encoding,
         shall always contain the value 0x000000)

   EtherType - Protocol type of encapsulated payload (for IPv6, shall
               always contain the value 0x86DD)

   FCS - Frame Check Sequence

   ED - Ending Delimiter

   FS - Frame Status


Maximum Transmission Unit

   IEEE 802.5 networks have a maximum packet size based on the maximum
   time a node may hold the token. This time depends on many factors
   including the data signalling rate and the number of nodes on the
   ring. The determination of maximum packet size becomes even more
   complex when multi-ring networks with bridges are considered.

   The possible ranges for MTU sizes are 256-4472 octets (for 4 Mbit/s
   rings) and 256-17800 octets (for 16 Mbit/s rings). This variation
   suggests that implementations must rely on static configuration or
   router advertisements [DISC] to determine actual MTU sizes. Common
   default values include 2002 octets (4 Mbit/s rings) and 8188 octets
   (16 Mbit/s rings).

   In a environment using source route bridging, the process of
   discovering the MAC-level route to a neighbor can yield the MTU for
   the path to that neighbor. The information is contained in the
   largest frame subfield of the routing information field. The
   following table lists the possible values of that subfield, and the
   IPv6 MTU size that results. If an implementation uses this
   information to determine MTU sizes, it must maintain separate MTU
   values for each neighbor.

                 LF (binary)   MAC MTU      IP MTU

                     000          552         508
                     001         1064        1020
                     010         2088        2044
                     011         4136        4092
                     100         8232        8188









Thomas                    Expires February 1996                 [Page 3]



INTERNET-DRAFT            IPv6 over Token Ring           August 24, 1995


Stateless Autoconfiguration and Link-local Addresses

   The address token [CONF] for a Token Ring interface is the
   interface's built-in 48-bit IEEE 802 address, in canonical bit
   order. A different MAC address set manually or by software should
   not be used as the address token.

   An IPv6 address prefix used for stateless autoconfiguration of a
   Token Ring interface must be 80 bits in length.

   The IPv6 Link-local address [AARCH] for a Token Ring interface is
   formed by appending the interface's IEEE 802 address to the 80-bit
   prefix FE80::.

                   +-------+-------+-------+-------+
                   |  FE      80      00      00   |
                   +-------+-------+-------+-------+
                   |  00      00      00      00   |
                   +-------+-------+-------+-------+
                   |  00      00   |               |
                   +-------+-------+               |
                   |      Token Ring Address       |
                   +-------+-------+-------+-------+


Address Mapping - Unicast

   The procedure for mapping IPv6 addresses into Token Ring link layer
   addresses is described in [DISC]. The Source/Target Link Layer
   Address option has the following form when the link layer is Token
   Ring.

                   +-------+-------+-------+-------+
                   | Type  |Length |               |
                   +-------+-------+               |
                   |      Token Ring Address       |
                   +-------+-------+-------+-------+

   Option Fields:

   Type    1 for Source Link Layer Address
           2 for Target Link Layer Address

   Length  1 (in units of 8 octets)

   Token Ring Address
           The 48-bit IEEE 802 address, in canonical bit order.






Thomas                    Expires February 1996                 [Page 4]



INTERNET-DRAFT            IPv6 over Token Ring           August 24, 1995


Address Mapping - Multicast

   All IPv6 packets with multicast destination addresses are
   transmitted to the Token Ring functional address 03-00-00-20-00-00
   (in canonical form). Note that protocols other than IPv6 may use
   this same functional address, so all frames destined to this address
   are not guaranteed to be IPv6 packets.


Security Considerations

   Security considerations are not addressed in this memo.


References

   [8025] IEEE Standards for Local Area Networks: Token Ring Access
        Method and Physical Layer Specifications. IEEE Std 802.5-1989.

   [AARCH] R. Hinden, S. Deering, IP Version 6 Addressing Architecture.
        Currently draft-ietf-ipngwg-addr-arch-03.txt.

   [CONF]  S. Thomson, IPv6 Stateless Address Autoconfiguration.
        Currently draft-ietf-addrconf-ipv6-03.txt.

   [DISC]  T. Narten, E. Nordmark, W. A. Simpson, Neighbor Discovery
        for IP Version 6 (IPv6).  Currently draft-ietf-ipngwg-
        discovery-01.txt.

   [IPV6]  S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)
        Specification.  Currently draft-ietf-ipngwg-ipv6-spec-02.txt.


Author's Address

   Stephen Thomas
   AT&T Tridom                 Phone: (770) 514-3522
   840 Franklin Court          Fax:   (770) 514-3491
   Marietta, GA 30067  USA     Email: stephen.thomas@tridom.com














Thomas                    Expires February 1996                 [Page 5]


________________________
Stephen A. Thomas
4397 Windsor Oaks Circle
Marietta, GA  30066-2387
E-mail: s.thomas@acm.org

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Thu Aug 24 18:04:55 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16444; Thu, 24 Aug 95 18:04:55 PDT
Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA16438; Thu, 24 Aug 95 18:04:46 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA25701; Thu, 24 Aug 1995 17:53:32 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id RAA01022; Thu, 24 Aug 1995 17:53:07 -0700
Date: Thu, 24 Aug 1995 17:53:07 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508250053.RAA01022@bobo.Eng.Sun.COM>
To: ipng@sunroof
Subject: (IPng 608) Proposed change to Neighbor Discovery packet formats
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


As we presented at the Stockholm IETF we would like to
increase robustness in ND by requiring that all ND packets must
be sent using a link-local source address.

In the current spec (draft-ietf-ipngwg-discovery-01.txt) 
all messages but Neighbor Solicitation and Neighbor Advertisement
are sent with link-local source addresses.

Without these proposed changes it is possible for any node in
the internet to accidentally or intentionally send a Neighbor 
Solicitation or a Neighbor Advertisement to an unsuspecting target 
node providing a bogus link-layer address of of one of the 
target's neighbors.

With these changes that hole will be closed. All ND messages must
be sent using a link-local address and the receivers must ignore
messages for which this is not the case. Also, all ND messages
except redirect must be sent to a link-local destination address (either
a link-local unicast address or a multicast address with link-local
scope), and receivers should ignore messages that do not satisfy that
requirement. This prevents ND messages from leaking through routers.
(The redirect messages will be "leaked" unless the routers refuse to
forward packets with a link-local source.)


There were no objections raised at Stockholm so we want to solicit the
mailing list for any additional comments.

The changes to the packet format are:

 - A new "ICMP Sender Address" field in the fixed part of the Neighbor 
   Solicitation. This makes the Neighbor Solicitation 16 bytes longer.

 - A new "Secondary Advertisement" flag in the Neighbor Advertisement.
   This does not change the size of the Neighbor Advertisement message.


Neighbor Solicitation:
----------------------

The IP Source Address field must contain the link-local address of
the interface. 

The ICMP Sender Address field should contain the
source address in the packet that prompted the solicitation,
if that address belongs to the interface, to ensure
that the receiver of the solicitation acquires the link-layer address
for return traffic.

When a node is the target of a received valid Neighbor Solicitation
it creates a neighbor cache entry for both the IP Source Address and
the ICMP Sender Address using a received Source Link-layer address
option.


Neighbor Advertisement:
-----------------------

When sending a Neighbor Advertisement for an anycast address 
or when proxying for some address, the Secondary Advertisement flag
MUST be set.  This allows the receiver of the Neighbor Advertisement
to select the fastest responding anycast "provider" or proxy while
updating the cached link-layer address from primary advertisements.

The receiver of the Neighbor Advertisement will use the Secondary 
Advertisement flag to determine if the Target Link-layer address
should replace an existing address. (In the current specification
this is determined by comparing the IP Source Address and the 
ICMP Target Address.) If the flag is set a cached link-layer address
will not be updated; otherwise a cached link-layer address
is updated.


Motivation for the changes:
---------------------------

A problem arises with requiring that Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages use a link-local source
address. Consider the following scenario:

Nodes A & B are about to communicate with each other. Neither knows
the other's link-layer address. Both also have link-local and normal
(e.g., global-scope) addresses.  The global-scope addresses are the
transport addresses used for the communication.

1) A initiates communication, but must first send out a NS message
asking for B's link layer address. The ND message contains:

       IPv6 Source: XXX (see below)
       IPv6 Destination: solicited-node multicast address
       ND target address: B
       Optional link-layer address: A's link-layer address

2) B receives the NS and creates a Neighbor Cache entry for XXX
containing A's link-layer address.  B then returns an NA containing:

       IPv6 Source: YYY (value not important in this example)
       IPv6 Destination: A
       ND target: B
       Optional link-layer address: B's link-layer address


3) A receives the message, adds B's link-layer address to its cache
and sends the data packet to B.

4) B passes the data packet to the upper layer, which then generates a
message to send to A.

5) Before sending the message to A, B examines its Neighbor Cache for
an entry for A.  If it does not have an entry, it must first perform
address resolution by sending out a NS.

Here is where the problem arises.  B will only have an entry in
its cache for A if the address XXX in 1) is A's global-scope
address.  If XXX is A's link-local address, a second NS/NA
packet exchange is needed to get A's link-layer address before
communication proceeds.




------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 21:11:15 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17795; Sun, 27 Aug 95 21:11:15 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17789; Sun, 27 Aug 95 21:11:06 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15214; Sun, 27 Aug 1995 20:59:46 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id UAA10511; Sun, 27 Aug 1995 20:59:48 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15052(4)>; Sun, 27 Aug 1995 20:59:38 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 20:59:32 -0700
To: ipng@sunroof.Eng.Sun.COM
Cc: deering@parc.xerox.com
Subject: (IPng 609) changes to Last Call'ed specs
Date: Sun, 27 Aug 1995 20:59:26 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.205932pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

At the request of our ADs, I prepared the following list of agreed-upon
changes and outstanding issues with the set of specs that underwent
IETF-wide Last Call in June and July.  Please let me know of any errors
or omissions.

Steve

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

IPv6 Specification
------------------

The following changes were posted to the IETF list immediately following
the Last Call, so I think we can consider them to also have been Last Called:

  - In the examples of how to lay out options, on page 29, two places
    where it says "Hdr Ext Len=1" should be "Hdr Ext Len=3"
    (reported by Hamid Asayesh).

  - In section 6, Flow Labels, I forgot to include the Priority field
    in the list of fields that must have the same value for all
    packets in the same flow (reported by Markus Jork).

  - The description of what the Jumbo Payload Length field covers
    should be made clearer (reported by Christian Huitema).

The following changes were proposed by Charlie Lynn in the only "formal"
response to the Last Call, and accepted at the first ipngwg meeting in
Stockholm:

  - For options containing data that can change en-route (and which therefore
    have the third-highest-order bit of their Option Type set to 1), make it
    clear that *all* bytes of the Option Data field are to be excluded from
    the Authentication function, and explain that "excluded" means "treated
    as if they were all zero-valued bytes".

  - Change the Routing Header to enable it to be ignored by final destinations
    that do not understand the Routing Type.  In Stockholm, Deering proposed,
    and the attendees agreed with, the following revised format for the
    first 32 bits of the Routing Header, for all Routing Types:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |

    where

	Hdr Ext Len   is the length of the header in 8-octet units, not
	              including the first 8 octets

	Segments Left is the number of "legs" left to traverse in the
                      route; if this value is zero, the receiver may
	              ignore this header (i.e., it indicates that the
	              route has been completed), whether or not the
	              receiver understands the Routing Type

The following additional changes were agreed to either on the mailing list
or in the Stockholm meetings:

  - "Improve" the host/router terminology.  What I propose to do is add a
    footnote to the terminology section saying something like this:

	* it is possible, though unusual, to have a device with multiple
          interfaces configured to forward non-self-destined packets
          arriving from some set (fewer than all) of its interfaces, and
	  to discard non-self-destined packets arriving from its other
	  interfaces.  Such a device must obey the protocol requirements
	  for routers when receiving packets from, and interacting with
	  neighbors over, the former (forwarding) interfaces.  It must
	  obey the protocol requirements for hosts when receiving packets
	  from, and interacting with neighbors over, the latter (non-
	  forwarding) interfaces.

    Comments?

  - Clarify the operation of Type 0 Routing Header by giving an example,
    showing the values of the header fields on each segment of the route.

  - Clarify the handling of options, extension headers, Next Header fields,
    etc. for fragmented packets by giving a few examples of packets before
    and after fragmentation (suggested by Dimitry Haskins and others).

  - Specify that fragments cannot reassemble to form a jumbogram (suggested
    by Craig Metz).


ICMPv6 Specification
--------------------

  - Add note warning about the possibility of upper-layer header being
    truncated from the returned packet in an error message, due to large
    number of extension header bytes, which can defeat delivery of the
    error message to the guilty upper-layer protocol instance.

  - Delete description of pseudo-header, replacing it with a reference to
    the description in the IPv6 spec (suggested by Alistair Bell and
    Marc Hasson).

  - Correct example of usage of the pointer in the Parameter Problem
    message on page 15, by changing "48" to "40" (reported by Dimitry
    Haskins and Francis Dupont).

  - Note that there is another exception to the "no ICMP error messages
    in response to multicasts" rule, which is "unrecognized option"
    Parameter Problem messages in response to options with high-order
    bits "10..." (reported by Dimity Haskins).

Address Architecture Document
-----------------------------

  - Add definition of "link-local address" to the terminology section
    (suggested by Jim Bound).

  - Specify that "::" is a legal text representation of the Unspecified
    (all-zeros) Address (suggested by Francis Dupont).

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

The following suggestions in Charlie Lynn's formal response to the Last Call
were rejected at the Stockholm meeting:

  - Add a bit to the Routing Header indicating whether or not it was
    inserted into the packet en-route, i.e., by a node other than the
    packet's originator.

      reasons for rejection: insertion of extension headers en-route breaks
      PMTU-discovery and can result in ICMP error messages being sent to
      non-guilty parties.  The desired effect can be achieved, and those
      problems avoided, by using en-route encapsulation (with optional
      Routing Header) rather than header insertion.

  - Change ICMP error messages to contain explicit fields identifying the
    upper-layer protocol to which the error message should be delivered.

      reasons for rejection: considered unnecessary complexity to handle the
      rare case of truncation of transport header from the returned packet
      because of too many extension header octets.  Such error messages are
      still usable for problem diagnosis other than in the upper-layer
      itself, e.g., if logged at IPv6 layer or observed in a packet trace.
      Will add warning to the ICMPv6 spec about consequences of long
      extension header on ICMP error message dispatching.

  - Change Security Considerations section of ICMPv6 spec to specify when
    and how to include an Authentication Header in ICMP error messages.

      reasons for rejection: group consensus that this belongs in aa
      IPsec spec instead.

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

The following issues and suggestions have been discussed on the mailing list
since the base specs went to Last Call, but no group consensus on these issues
has been reached yet:

  - Fragmentation issues:
	- change the minimum reassembly buffer size to a number larger
	  than 576?
	- specify that sources of fragmented packets must use the minimal
	  number of fragments required to fit in the perceived PMTU?
	- specify that all fragments with the M bit set must be no less
	  than 7 octets shorter than the perceived PMTU?
	- specify that all fragments with the M bit set must be no shorter
	  than 576 octets?
	- ignore fragments that partially overlap other fragments of the
	  same packet, or discard any packet that arrives as partially
	  overlapping fragments?

  - Routing Header issues:
	- add a "Total Length" field to the fragment header, carrying the
	  length of the original, unfragmented packet?
	- forbid forwarding of packets with Routing Headers by hosts?
	  (if not, make it clearer that hosts are expected to forward
	  packets with Routing Headers, if they are intermediate targets
	  of such packets.)
	- specify the reversing rules for packets that are responses to
	  packets that carry a Routing Header?
	- forbid or discourage reversal of an unauthenticated Routing Header?
	- forbid or discourage acceptance of a packet with an unauthenticated
	  Routing Header?

  - Allow the transport-layer checksum to be omitted when the Authentication
    header (or the ESP header?) is being used?

  - Add a Congestion Indication bit to the base IPv6 header?

  - Add MUST/SHOULD/MAY conformance requirements for all IPv6 fields and
    functions?

  - Build a single Terminology document, to be shared (either by reference
    or inclusion) in all IPv6-related specs?

  - Allow the use of zero in the UDP Length field to indicate that the UDP
    length should be derived from the Jumbogram Option?

Note: the above list does not include issues concerning those specs that
have not yet been subjected to WG or IETF Last Call, e.g., the Neighbor
Discovery spec.

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 22:07:53 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17824; Sun, 27 Aug 95 22:07:53 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17818; Sun, 27 Aug 95 22:07:44 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA16509; Sun, 27 Aug 1995 21:56:24 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id VAA15043; Sun, 27 Aug 1995 21:56:26 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15085(3)>; Sun, 27 Aug 1995 21:56:13 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 21:56:06 -0700
To: dhaskin@baynetworks.com (Dimitry Haskin)
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
Subject: (IPng 610) Re:  fragmentation question 
In-Reply-To: dhaskin's message of Thu, 22 Jun 95 15:28:39 -0800.
             <9506222228.AA23384@BayNetworks.com> 
Date: Sun, 27 Aug 1995 21:55:58 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.215606pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

On Thu, 22 Jun 1995, Dimitry Haskin wrote:

> Should it be required that all fragments of a fragmented packet carry
> identical extension headers, i.e. in each fragment the fragment
> header MUST be at the same offset from the beginning of packet.
> 
> This is not clear from the spec.

(yeah, I'm finally getting around to responding to some mail from
two months ago!)

This is one of those "be conservative in what you send, and liberal in what
you receive" things.  That is, the sender SHOULD supply the same set of
extension headers preceding the Fragment header on all fragments of the
same original packet, but the receiver MUST NOT require that to be true.
Thus, the receiver must not depend on the Fragment header being at the
same relative location in all fragments of the same packet.

In the case where the different fragments have different extension headers,
only the ones from the initial fragment (the one with Fragment Offset = 0)
appear in the reassembled packet.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 22:28:42 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17843; Sun, 27 Aug 95 22:28:42 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17837; Sun, 27 Aug 95 22:28:33 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA17089; Sun, 27 Aug 1995 22:17:13 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id WAA16488; Sun, 27 Aug 1995 22:17:15 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15089(6)>; Sun, 27 Aug 1995 22:17:05 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 22:16:53 -0700
To: Markus Jork <jork@nestvx.enet.dec.com>
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
Subject: (IPng 611) Re:  ICMPv6 group membership messages 
In-Reply-To: jork's message of Thu, 27 Jul 95 10:51:46 -0800.
             <9507271651.AA18441@vbormc.vbo.dec.com> 
Date: Sun, 27 Aug 1995 22:16:50 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.221653pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

On Thu, 27 Jul 1995, Markus Jork wrote:

> Do nodes send group membership messages (query, report and termination)
> for IPv6 link-local scope multicast addresses? These include the all-nodes,
> all-routers, DHCP and solicited-node addresses.
> The same question for node-local addresses.
> 
> This doesn't seem to make sense because these group membership messages are
> used to provide information to multicast routers, which have no business in
> forwarding these kind of multicast addresses anyway.

Good question!  My first reaction is to agree with you that it doesn't
make sense to use the group membership messages for link-local scope
multicast addresses.  However, I have had it in the back of my mind for
some time to extend the membership protocol to allow routers to send some
kind of "prune" message to an individual source host, in the case where there
are no destination group members anywhere in the Internet, including on the
first-hop link -- under the current protocol, a multicast packet always
gets sent on the first-hop link, even if there are no group members anywhere.
Presumably, this "host pruning" functionality would be useful even for
link-local addresses; however, that would require that the routers be
able to learn of the presence of members of link-local groups, thus suggesting
the use of the membership protocol for those groups too.

One of the reasons we haven't done this yet for IPv4 is the denial-of-service
hazard that arise from having an unauthenticated "shut up!" message that is
obeyed by any multicast source.  The IPv6 authentication machinery *might*
offer a solution to that problem some day (once we figure out how to
authenticate the othe rkinds of ICMP messages).  Or maybe we just have
hosts check that the source of the prune message is itself a link-local
address, so at least the bad guys are restricted to those on the same link.

Sorry for rambling.  As I said, you asked a good question, for which the
answer is not completely obvious to me.

> I couldn't find anything about this in the specs ("ICMPv6" and "IPv6
> Addressing Architecture").

Right.  We need to issue a revision of RFC-1112, decribing the group
membership protocol for IPv6.  Bill Fenner here at PARC has just finished
a draft of the IGMPv2 spec, which updates RFC-1112 to the current version
of the membership protocol for IPv4.  Maybe I can get him to whip off
an IPv6 version of the same document.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 22:48:10 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17863; Sun, 27 Aug 95 22:48:10 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17857; Sun, 27 Aug 95 22:47:59 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA17662; Sun, 27 Aug 1995 22:36:38 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id WAA17539; Sun, 27 Aug 1995 22:36:40 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15093(1)>; Sun, 27 Aug 1995 22:36:36 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 22:36:24 -0700
To: Richard Stevens <rstevens@noao.edu>
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
Subject: (IPng 612) Re:  reversal of source routes 
In-Reply-To: rstevens's message of Fri, 28 Jul 95 15:30:11 -0800.
             <9507282230.AA13765@gemini.tuc.noao.edu> 
Date: Sun, 27 Aug 1995 22:36:15 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.223624pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

On Fri, 28 Jul 1995, Rich Stevens wrote:

> In the API draft (ipngwg-bsd-api-02.txt) the statement is made (p. 12)
> that "In order for source routing to operate properly, the node receiving
> a request packet that bears a source route must reverse that source route
> when sending the reply."  But in the mobility draft (perkins-ipv6-mobility-
> sup-02.txt) is states (p. 10) "In particular, it is fortunate that IPv6
> routing headers do not carry the semantics which require reversal of
> source routes."  So I went to the protocol draft (ipngwg-ipv6-spec-02.txt)
> and found it says nothing about source route reversal.
> 
> What are the rules regarding source route reversal?

Rich,

There aren't any rules yet.  Some people think you should never reverse
source routes for sending replies; others think you should reverse the
source route to reply to an authenticated packet only; almost no one thinks
you should reverse the source route from an unauthenticated packet.

One issue that arises is the possible need to make a choice between a
reversed source route and a different source route that has been specified
for outgoing packets as a local policy decision.  Which one takes precedence?
Should you try to somehow "merge the two"?  Yuck.

In any case, I consider this to be an upper-layer issue (i.e., above the
IP layer), since IP itself has no notion of "reply" packets.  Thus, I
think it's perfectly reasonable for the API draft to include a method
of receiving an incoming Routing header, and supplying an outgoing
Routing header that may or may not be derived by reversing an incoming one.
Nonetheless, it would probably be a Good Thing for us to agree on the
MUST/SHOULD/MAY status of route reversal.  Do you have an opinion on this
matter?

(By the way, I'm surprised by the quote you gave from Charlie Perkin's
mobility draft, since I thought Charlie was a big fan of source-route
reversal!)

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 23:00:55 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17887; Sun, 27 Aug 95 23:00:55 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17881; Sun, 27 Aug 95 23:00:47 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA18092; Sun, 27 Aug 1995 22:49:28 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id WAA18571; Sun, 27 Aug 1995 22:49:29 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15091(6)>; Sun, 27 Aug 1995 22:49:17 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 22:49:14 -0700
To: mark@mentat.com (Marc Hasson)
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
Subject: (IPng 613) Re:  ICMPv6 pseudo-header 
In-Reply-To: mark's message of Thu, 10 Aug 95 01:50:34 -0800.
             <9508102350.AA12684@orna.mentat.com> 
Date: Sun, 27 Aug 1995 22:49:04 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.224914pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

On Thu, 10 Aug 1995, Marc Hasson wrote:

> Both the Base spec (draft-ietf-ipngwg-ipv6-spec-02) on pages 25-26 and
> the ICMP spec (draft-ietf-ipngwg-icmp-02.txt) on pages 5-8 discuss the
> ICMPv6 pseudo-header calculation.  But they are somewhat inconsistent
> with each other.  They specify different orderings of the payload
> length and the "next hdr" is in a different spot.  There's also some
> differences in the explanatory texts, just due to having 2 copies of
> this.  My belief is that both descriptions are technically correct and
> will give the same checksum result.  However, having the 2 descriptions
> leads one to think there's something different between the two and may
> unnecessarily encourage separate pseudo-header calculation routines to
> be implemented or mistakes to be made.  And why should future implementers
> spend *any* time thinking about those differences in the documents?

Marc,

Yes, both descriptions yield the same result, but yes, it's a bad idea
to have two different descriptions.  We'll replace the description in
the ICMP spec with a pointer to the description in the IPv6 spec.
Thanks for pointing that out.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 23:24:32 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17915; Sun, 27 Aug 95 23:24:32 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17909; Sun, 27 Aug 95 23:24:24 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA18752; Sun, 27 Aug 1995 23:13:05 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id XAA20075; Sun, 27 Aug 1995 23:13:06 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15097(6)>; Sun, 27 Aug 1995 23:12:50 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 23:12:46 -0700
To: Stephen Thomas <sthomas@mindspring.com>
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
Subject: (IPng 614) Re:  IPv4-{compatible,mapped} Class D addresses 
In-Reply-To: sthomas's message of Fri, 11 Aug 95 14:01:33 -0800.
             <199508112115.RAA01242@dylan.mindspring.com> 
Date: Sun, 27 Aug 1995 23:12:45 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.231246pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

On Fri, 11 Aug 1995, Stephen Thomas wrote:

> Since draft-ietf-ipngwg-addr-arch-03.txt seems to be silent on this
> one, I bring it up as a question. Are the embedded IPv4 address formats
> intended to support Class D addresses as well as unicast ones?

No.

> I rather hope not, as that requires more than simply checking the
> 8-bit format prefix to recognize a multicast address.

Exactly.

> If I may be so bold, could we set aside the 16-bit format prefix
> FFFF::/16 for embedded IPv4 class D addresses? That would allow
> us to preserve checksums in the conversion from IPv4 to IPv6.

I question the value of trying to do IPv4 <-> IPv6 translation of multicast
packets.  If you try to support "mixed" groups of v4 and v6 nodes, you
could end up having to transmit two copies of each multicast packet on
any links where there were group members of both kinds, which could be
quite expensive for high-data-rate multicasts like video.

The installed base of IPv4 multicast-capable machines and applications is
still a tiny fraction of the total IPv4 base, and my hunch (hope?) is that
the folks who have gone to the effort of installing IP multicast host and
routing software are the "early adopter" types who will also probably pick
up IPv6 before most others, so I suspect it's not worth putting a lot of
effort into transition mechanisms for IP multicast.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 23:40:18 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17939; Sun, 27 Aug 95 23:40:18 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17933; Sun, 27 Aug 95 23:40:09 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19349; Sun, 27 Aug 1995 23:28:51 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id XAA21520; Sun, 27 Aug 1995 23:28:51 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15092(1)>; Sun, 27 Aug 1995 23:28:41 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 23:28:32 -0700
To: Dan McDonald <danmcd@cs.nrl.navy.mil>
Cc: IPng Mailing list <ipng@sunroof2.Eng.Sun.COM>, deering@parc.xerox.com
Subject: (IPng 615) Re:  One more thing about overlapping fragments 
In-Reply-To: danmcd's message of Tue, 22 Aug 95 14:08:02 -0800.
             <9508222108.aa21465@cs.nrl.navy.mil> 
Date: Sun, 27 Aug 1995 23:28:31 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.232832pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

On Tue, 22 Aug 1995, Dan McDonald wrote:

> One more thing, reassembly should be done before ANY OTHER options are
> exercised, even hop-by-hop options which come before the fragment header.
> Why?  Well, consider a packet that was authenticated.  The authentication
> header comes AFTER fragmentation in the order of headers; this means that
> authentication will only happen after reassembly.
> 
> Although no such hop-by-hop option exists yet, I'd imagine that someday
> there might be one that I don't want to have executed at my endpoint until I
> know that packet is authentic.

Dan,

I mildly disagree.  Those hop-by-hop options are also going to be processed
at all the routers on the way to get to you, and they won't be able to
authenticate them, so the receiver's vulnerability is no worse than
the routers.  (No, I don't believe we'll ever see widespread use of
authentication-verification of forwarded packets by routers, at least
not with the currently defined Authentication header.  Now if they had
followed my advice and made Authentication an option rather than a
separate header, it could properly appear either as a hop-by-hop option
or as a destination option, depending on whether you wanted en-route
or end-to-end authentication.  That would be the V6 Way.)

I think you should process the headers in the order they appear in the
packet.  If you want to postpone any potentially-harmful state changes
requested by a hop-by-hop option until you reach and process the
Authentication header, that's fine, but at least make an initial pass
over the hop-by-hop options and do anything that can't hurt you.  Maybe.

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Sun Aug 27 23:57:27 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17956; Sun, 27 Aug 95 23:57:27 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA17950; Sun, 27 Aug 95 23:57:19 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA19879; Sun, 27 Aug 1995 23:46:00 -0700
Received: from alpha.xerox.com by mercury.Sun.COM (Sun.COM)
	id XAA22747; Sun, 27 Aug 1995 23:46:00 -0700
Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15087(1)>; Sun, 27 Aug 1995 23:45:52 PDT
Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 27 Aug 1995 23:45:49 -0700
To: ipng@sunroof.Eng.Sun.COM
Cc: deering@parc.xerox.com
Subject: (IPng 616) WG Last Call on IPv6 NSAP spec
Date: Sun, 27 Aug 1995 23:45:37 PDT
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <95Aug27.234549pdt.75270@digit.parc.xerox.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

At one of the ipngwg meetings in Stockholm, we agreed to submit the
"OSI NSAPs and IPv6" draft to the IESG as an Experimental status RFC,
pending a Working Group Last Call.  So this is that Last Call, starting
now and ending two weeks from today, on Sunday, September 10.  Please
send any technical corrections or comments to this mailing list; please
send spelling/grammer/etc. corrections to the authors only.

This Last Call applies to the following draft, which was made available
a few days ago:

       Title     : OSI NSAPs and IPv6                                      
       Author(s) : J. Bound, B. Carpenter, D. Harrington, 
                   J. Houldsworth, A. Lloyd
       Filename  : draft-ietf-ipngwg-nsap-ipv6-00.txt
       Pages     : 17
       Date      : 08/23/1995

Steve

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 28 09:46:45 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18232; Mon, 28 Aug 95 09:46:45 PDT
Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18226; Mon, 28 Aug 95 09:46:36 PDT
Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id JAA03822; Mon, 28 Aug 1995 09:35:04 -0700
Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4)
	id JAA03710; Mon, 28 Aug 1995 09:34:37 -0700
Date: Mon, 28 Aug 1995 09:34:37 -0700
From: nordmark@jurassic-248 (Erik Nordmark)
Message-Id: <199508281634.JAA03710@bobo.Eng.Sun.COM>
To: deering@parc.xerox.com
Subject: (IPng 617) Re:  changes to Last Call'ed specs
Cc: ipng@sunroof
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>   - "Improve" the host/router terminology.  What I propose to do is add a
>     footnote to the terminology section saying something like this:
> 
> 	* it is possible, though unusual, to have a device with multiple
>           interfaces configured to forward non-self-destined packets
>           arriving from some set (fewer than all) of its interfaces, and
> 	  to discard non-self-destined packets arriving from its other
> 	  interfaces.  Such a device must obey the protocol requirements
> 	  for routers when receiving packets from, and interacting with
> 	  neighbors over, the former (forwarding) interfaces.  It must
> 	  obey the protocol requirements for hosts when receiving packets
> 	  from, and interacting with neighbors over, the latter (non-
> 	  forwarding) interfaces.
> 
>     Comments?

The text gives the impression that forwarding (non-self-destined packets)
is a property related to receiving packets. Isn't it the case that if
(non-self-destined) packets received on interface A are forwarded out 
interface B then both A and B will have to be in the forwarding set 
of interfaces?

I can imagine that e.g. Reverse Path forwarding based multicast routing
breaks if packets arriving on B are not forwarded out interface A.

Can the text be clarified to point this out?

   Erik

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Mon Aug 28 11:19:36 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18420; Mon, 28 Aug 95 11:19:36 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18414; Mon, 28 Aug 95 11:19:24 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA03200; Mon, 28 Aug 1995 11:07:53 -0700
Received: from MVS.OAC.UCLA.EDU by mercury.Sun.COM (Sun.COM)
	id LAA29850; Mon, 28 Aug 1995 11:07:38 -0700
Message-Id: <199508281807.LAA29850@mercury.Sun.COM>
Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1)
   with BSMTP id 1060; Mon, 28 Aug 95 11:07:53 PST
Date:    Mon, 28 Aug 95 11:07 PDT
To: Matt Crawford <crawdad@FNAL.FNAL.GOV>
Cc: Matt Thomas <matt@LKG.DEC.COM>, ipng@SUNROOF.Eng.Sun.COM, dan@LKG.DEC.COM,
        bound@ZK3.DEC.COM
From: Michael Stein                        <OSYSMAS@MVS.OAC.UCLA.EDU>
Subject: (IPng 618) Re: IPv6 fragments: can they overlap?
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> In IPv4 you couldn't impose this condition because a packet could be
> duplicated, then the two copies could be fragmented differently by
> routers.  Routers don't fragment forwarded IPv6 packets, but a
> fragment could still be duplicated.  I don't think the extra hair to
> distinguish a duplicated fragment from an overlapping fragment will
> pay off in security.

That's not the only way an IPv4 network can result in overlaping
fragments, it doesn't require the routers to fragment!

  (IPv4 RFC791 on identification field)
    It is appropriate for some higher level protocols to choose
    the identifier. For example, TCP protocol modules may
    retransmit an identical TCP segment, and the probability for
    correct reception would be enhanced if the retransmission
    carried the same identifier as the original transmission
    since fragments of either datagram could be used to construct
    a correct TCP segment.

This has the higher level protocols (than IP) determining the
packet ID field and possibly using the same value to send the
same packet.  If the IP layer does fragment this second send of
the same packet in a different way than the first send then
overlaping fragments are possible.

So is this DISALLOWED by IPv6?

In the IPv6 draft, it says:

     The original payload is assigned an Identification value
     that is different than that of any other fragmented payload
     sent recently* with the same IPv6 Source Address, IPv6
     Destination Address, and Fragment Next Header value.

Does this "different" include resending the same packet?

(It's not any "other" packet, so could it still use the
same ID value?)
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 29 03:24:43 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18953; Tue, 29 Aug 95 03:24:43 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18947; Tue, 29 Aug 95 03:24:24 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA24182; Tue, 29 Aug 1995 03:13:03 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id DAA12844; Tue, 29 Aug 1995 03:13:00 -0700
Message-Id: <m0snO5m-00013hC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 619) Re:  changes to Last Call'ed specs
To: deering@parc.xerox.com (Steve Deering)
Date: Tue, 29 Aug 1995 11:40:29 +0100 (BST)
Cc: ipng@sunroof.Eng.Sun.COM, deering@parc.xerox.com
In-Reply-To: <95Aug27.205932pdt.75270@digit.parc.xerox.com> from "Steve Deering" at Aug 27, 95 08:59:26 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> The following issues and suggestions have been discussed on the mailing list
> since the base specs went to Last Call, but no group consensus on these issues
> has been reached yet:
> 
> 	- specify that all fragments with the M bit set must be no less
> 	  than 7 octets shorter than the perceived PMTU?

Very very bad.

> 	- specify that all fragments with the M bit set must be no shorter
> 	  than 576 octets?

Even worse. I want the right for hosts to use a preferred MTU below
the 576 byte boundary on some networks, _providing_ they will always
accept the required 576 byte frames. Implementation issues dont belong
in the IPv6 spec.

These two needlessly prevent a fragment sending optimisation where the
packets are sent with the first fragment last. The first fragment may
cause the second fragment to be shorter than the PMTU in order to keep
the entire TCP header in one fragment. This technique allows a single
pass copy/checksum/fragment and thus performance improvements.

Thus I feel that specifying the nature of fragmentation is an implementation
issue and not appropriate for the base specification.

Add discussion of passing the entire packet length in the fragment header
so that people can preallocate buffers, drop frames that will assemble
as too large and make sensible time/space guesstimates. This assumes accepting
Craig's no reassembly into a jumbogram.


> 	- forbid or discourage reversal of an unauthenticated Routing Header?
> 	- forbid or discourage acceptance of a packet with an unauthenticated
> 	  Routing Header?

Add the words 'as default behaviour' and I'll go for that.

>   - Add MUST/SHOULD/MAY conformance requirements for all IPv6 fields and
>     functions?

This is an extremely good idea, providing people dont cross out everything
marked SHOULD and implement only the MUST's. So the MUST's have to be chosen
very carefully.

>   - Allow the use of zero in the UDP Length field to indicate that the UDP
>     length should be derived from the Jumbogram Option?

Sensible.

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 29 05:41:41 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18985; Tue, 29 Aug 95 05:41:41 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18979; Tue, 29 Aug 95 05:41:32 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28475; Tue, 29 Aug 1995 05:30:11 -0700
Received: from concorde.inria.fr by mercury.Sun.COM (Sun.COM)
	id FAA23180; Tue, 29 Aug 1995 05:30:10 -0700
Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.6.10/8.6.9) with ESMTP id OAA25618; Tue, 29 Aug 1995 14:29:59 +0200
Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id OAA29587; Tue, 29 Aug 1995 14:29:57 +0200
Message-Id: <199508291229.OAA29587@givry.inria.fr>
From: Francis Dupont <Francis.Dupont@inria.fr>
To: Steve Deering <deering@parc.xerox.com>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 620) Re:  changes to Last Call'ed specs 
In-Reply-To: Your message of Sun, 27 Aug 1995 20:59:26 PDT.
             <95Aug27.205932pdt.75270@digit.parc.xerox.com> 
Date: Tue, 29 Aug 1995 14:29:49 +0200
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

Destination Options header can be before the Routing header
or before the upper-layer (last) header (cf page 8, 4.1).
The semantics are very different:
 - in the first case options are processed by the first
destination plus subsequent destinations listed in the Routing
header (cf note 1)
 - in the second case options are processed only by the
final destination (cf note 3)
Clearly we need both the cases but it is annoying to have
same name and Next Header value for two different things
because we need to scan inside the header in order to know
in which case you are.
I propose to use different names and Next Header values.

Regards

Francis.Dupont@inria.fr

PS: in the second case good names are "Final Options header"
or better "End-to-End Options header" ?
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 29 05:45:24 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18998; Tue, 29 Aug 95 05:45:24 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA18992; Tue, 29 Aug 95 05:45:16 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA28716; Tue, 29 Aug 1995 05:33:54 -0700
Received: from mail2.digital.com by mercury.Sun.COM (Sun.COM)
	id FAA23713; Tue, 29 Aug 1995 05:33:45 -0700
From: bound@zk3.dec.com
Received: from xirtlu.zk3.dec.com by mail2.digital.com; (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA32487; Tue, 29 Aug 1995 05:17:08 -0700
Received: by xirtlu.zk3.dec.com; id AA16084; Tue, 29 Aug 1995 08:17:02 -0400
Message-Id: <9508291217.AA16084@xirtlu.zk3.dec.com>
To: iialan@iifeak.swan.ac.uk (Alan Cox)
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 621) Re: changes to Last Call'ed specs 
In-Reply-To: Your message of "Tue, 29 Aug 95 11:40:29 BST."
             <m0snO5m-00013hC@iiit.swan.ac.uk> 
Date: Tue, 29 Aug 95 08:16:56 -0400
X-Mts: smtp
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


>> 	- forbid or discourage reversal of an unauthenticated Routing Header?
>> 	- forbid or discourage acceptance of a packet with an unauthenticated
>> 	  Routing Header?

>Add the words 'as default behaviour' and I'll go for that.

Better yet....

add the words 'as default behaviour when security is in use'

Remember the mandate of security is that it must be implemented and may
not be in use.  We cannot force the world to use security if they don't
want to if it costs to much and kills performance on their nodes.

This gets to something I just questioned in the POISED WG.  We need to
understand the differences for reqs for the Internet and reqs for
private enterprise they are not "always" the same.  I pointed out in the
sdrp WG an example of a military application (I consider private
enterprise) where source routes and reversal are in fact mandated within
a private network.  For performance reasons security may not be in use
and a secure network medium is being used (at least relatively secure
where for example the ability to detect any patterns on the private network
have been secured for a reasonable distance X).  I think neither forbid
or discourage is the proper word for private networks.  

/jim
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 29 10:29:53 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA19156; Tue, 29 Aug 95 10:29:53 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA19150; Tue, 29 Aug 95 10:29:39 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA25534; Tue, 29 Aug 1995 10:17:59 -0700
Received: from sundance.itd.nrl.navy.mil by mercury.Sun.COM (Sun.COM)
	id KAA18609; Tue, 29 Aug 1995 10:17:54 -0700
Received: from loopback.nrl.navy.mil by cs.nrl.navy.mil id aa16513;
          29 Aug 95 18:13 GMT
To: Alan Cox <iialan@iifeak.swan.ac.uk>
Cc: ipng@sunroof.Eng.Sun.COM
Subject: (IPng 622) Re: changes to Last Call'ed specs 
In-Reply-To: Your message of "Tue, 29 Aug 1995 11:40:29 +0100."
             <m0snO5m-00013hC@iiit.swan.ac.uk> 
Date: Tue, 29 Aug 1995 13:13:28 -0500
From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
Message-Id:  <9508291813.aa16513@cs.nrl.navy.mil>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

In message <m0snO5m-00013hC@iiit.swan.ac.uk>, Alan Cox writes:
>> The following issues and suggestions have been discussed on the mailing list
>> since the base specs went to Last Call, but no group consensus on these issu
>> has been reached yet:
>> 
>> 	- specify that all fragments with the M bit set must be no less
>> 	  than 7 octets shorter than the perceived PMTU?
>
>Very very bad.

	This was discussed earlier, and I think that the most reasonable way
to handle this is to specify that all fragments with the M bit set except for
the last one in the chain SHOULD be no less than 7 octets shorter than the
perceived PMTU. This allows some freedom, and allows implementations where
the short fragment is last to conform to the recommendation. When you are
dealing with tunnels and security processing, you have potentially variable
(consider ESP DES-CBC, in which the padding is variable-length in order to make
the payload length be an integer multiple of the DES block size) overheads
that make it difficult to slice up fragments to meet mandatory sizing
requirements. Most of the time, you should be able to get within seven
octets without much trouble, but this may place an unreasonable complexity
burden on some systems.

>> 	- specify that all fragments with the M bit set must be no shorter
>> 	  than 576 octets?
>
>Even worse. I want the right for hosts to use a preferred MTU below
>the 576 byte boundary on some networks, _providing_ they will always
>accept the required 576 byte frames. Implementation issues dont belong
>in the IPv6 spec.

	Could you elaborate on this? I cannot see a case in which you would
want to use a PMTU lower than the minimum. If we specifically lower-bound
the fragment PMTU to the minimum MTU and disallow overlapping fragments, then
we almost eliminate the fragmentation-based attacks on transport-layer port
filtering that are currently being discussed over on Bugtraq and have been
discussed on Firewalls. (of course, IPsec is supposed to also do a lot to
solve this problem)

>These two needlessly prevent a fragment sending optimisation where the
>packets are sent with the first fragment last. The first fragment may
>cause the second fragment to be shorter than the PMTU in order to keep
>the entire TCP header in one fragment. This technique allows a single
>pass copy/checksum/fragment and thus performance improvements.

	This seems like time for a design-decision to me. On the one hand,
we have end-system performance. On the other hand, we have network bandwidth
and overhead. Which do we optimize for? Or do we specify things in terms of
SHOULDs and allow the implementor to choose?

>Add discussion of passing the entire packet length in the fragment header
>so that people can preallocate buffers, drop frames that will assemble
>as too large and make sensible time/space guesstimates. This assumes accepting
>Craig's no reassembly into a jumbogram.

	If it isn't too much trouble, having the total length somewhere in
the fragment header seems like a win to me, also. It lets you know exactly
how much space you need to allocate for a re-assembly buffer (or that you
don't have the space and need to toss the packet).

>> 	- forbid or discourage reversal of an unauthenticated Routing Header?
>> 	- forbid or discourage acceptance of a packet with an unauthenticated
>> 	  Routing Header?
>
>Add the words 'as default behaviour' and I'll go for that.

	I think that these SHOULD be configurable items in an end system,
and the forbid option MUST be available. If they aren't configurable, then
they MUST be forbidden, IMO.

>>   - Add MUST/SHOULD/MAY conformance requirements for all IPv6 fields and
>>     functions?
>
>This is an extremely good idea, providing people dont cross out everything
>marked SHOULD and implement only the MUST's. So the MUST's have to be chosen
>very carefully.

	It seems to me that all IPv6 header fields are MUSTs, period. Optional
headers themselves might be wholly optional, but if you implement the header,
you MUST implement all defined fields (implement may mean note-and-ignore
in some cases). Some possible exceptions to this thinking include priority
and flow processing...? (if you don't implement flows at all, you can't
really do anything with the Flow Label field, similarly with the priority
field)

>>   - Allow the use of zero in the UDP Length field to indicate that the UDP
>>     length should be derived from the Jumbogram Option?
>
>Sensible.

	What if the UDP payload is 65,500 bytes and you have options that make
the total length of the packet 66,000 bytes long? The packet has a payload
length of 0 in its IPv6 header and a jumbo-payload option with 65,960 (IPv6
header length isn't included, of course) in it. But the UDP payload length
could legitimately store the 65,500 in it, being a 16-bit field, and the
wording of the jumbogram rules says to me that you don't want to put a zero
in the length field if the length is <= 65,635.

									-Craig
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 29 10:40:01 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA19172; Tue, 29 Aug 95 10:40:01 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA19166; Tue, 29 Aug 95 10:39:48 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA27395; Tue, 29 Aug 1995 10:28:22 -0700
Received: from iiit.swan.ac.uk by mercury.Sun.COM (Sun.COM)
	id KAA21273; Tue, 29 Aug 1995 10:27:21 -0700
Message-Id: <m0snUs2-00013gC@iiit.swan.ac.uk>
From: iialan@iiit.swan.ac.uk (Alan Cox)
Subject: (IPng 623) Re: changes to Last Call'ed specs
To: cmetz@sundance.itd.nrl.navy.mil (Craig Metz)
Date: Tue, 29 Aug 1995 18:54:45 +0100 (BST)
Cc: ipng@sunroof.Eng.Sun.COM
In-Reply-To:  <9508291813.aa16513@cs.nrl.navy.mil> from "Craig Metz" at Aug 29, 95 01:13:28 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

> 	Could you elaborate on this? I cannot see a case in which you would
> want to use a PMTU lower than the minimum. If we specifically lower-bound
> the fragment PMTU to the minimum MTU and disallow overlapping fragments, then
> we almost eliminate the fragmentation-based attacks on transport-layer port
> filtering that are currently being discussed over on Bugtraq and have been
> discussed on Firewalls. (of course, IPsec is supposed to also do a lot to
> solve this problem)

Classic example is AX.25 networks. Supporting the 576 byte MTU is fine,
but performance will be best using lower values and intelligent use of
fragments (ie reissuing retransmits with the same fragment ID's). I'm
much less worried about this one.

> 	This seems like time for a design-decision to me. On the one hand,
> we have end-system performance. On the other hand, we have network bandwidth
> and overhead. Which do we optimize for? Or do we specify things in terms of
> SHOULDs and allow the implementor to choose?

Does anyone know which way we will need to have chosen for 20 years time. I
think not

Alan

------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Tue Aug 29 15:36:37 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA19405; Tue, 29 Aug 95 15:36:37 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA19399; Tue, 29 Aug 95 15:36:28 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA07915; Tue, 29 Aug 1995 15:24:59 -0700
Received: from thumper.bellcore.com by mercury.Sun.COM (Sun.COM)
	id PAA06158; Tue, 29 Aug 1995 15:24:49 -0700
Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.9/8.6.10) with ESMTP id SAA26210; Tue, 29 Aug 1995 18:24:43 -0400
Message-Id: <199508292224.SAA26210@thumper.bellcore.com>
To: ipng@sunroof.Eng.Sun.COM
Cc: gja@thumper.bellcore.com
Subject: (IPng 624) IPv6 over ATM I-D out in ip-atm WG.
Date: Tue, 29 Aug 1995 18:24:39 -0400
From: Grenville Armitage <gja@thumper.bellcore.com>
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk


An FYI for ipngwg:

The IP-ATM wg has been asked to add IPv6 over ATM to
its charter, and this has been done by the chair Mark Laubach.

As a result the IPv6/ND over ATM I-D has emerged (in typically
hacky first draft form) as:

	draft-ietf-ipatm-ipv6nd-00.txt

I've created a web page for this work.

	http://gump.bellcore.com:8000/~gja/iv6-drafts.html
 
Contributions to ip-atm are welcome. From the mailer:

X-Info: Submissions to ip-atm@matmos.hpl.hp.com
X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com

cheers,
gja
------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com

From owner-ipng  Wed Aug 30 16:47:10 1995
Return-Path: <owner-ipng>
Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA20220; Wed, 30 Aug 95 16:47:10 PDT
Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1)
	id AA20214; Wed, 30 Aug 95 16:47:01 PDT
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3)
	id AA15383; Wed, 30 Aug 1995 16:35:38 -0700
Received: from servo.ipsilon.com by mercury.Sun.COM (Sun.COM)
	id QAA00933; Wed, 30 Aug 1995 16:35:31 -0700
Received: from [204.160.241.224] (acacia.Ipsilon.COM [204.160.241.224]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id QAA07531; Wed, 30 Aug 1995 16:34:58 -0700
X-Sender: hinden@mailhost.ipsilon.com
Message-Id: <v02130516ac6aa2eb899e@[204.160.241.224]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Aug 1995 16:37:54 -0700
To: ipng@sunroof.Eng.Sun.COM
From: hinden@Ipsilon.COM (Bob Hinden)
Subject: (IPng 625) New IPv6 Addressing Related Internet Drafts
Cc: hinden@Ipsilon.COM
Sender: owner-ipng@sunroof.Eng.Sun.COM
Precedence: bulk

I have submitted two new IPv6 drafts to be Internet Drafts.

The first is "An IPv6 Provider-Based Unicast Address Format" which is an
update to (including minor change in title) to the previous version.  The
changes are
(a) to conform with the terminology used in the IPv6 Address Architecture
specification and (b) incorporate the changes agreed to in the Danvers meeting.

The second is a new draft titled "IPv6 Testing Address Allocation" which is
a plan for IPv6 address assignment to be used for IPv6 testing.

Until these drafts are available from the usual sources, they are available
for anonymous ftp from ftp.ipsilon.com in the pub/ipng directory as:

        draft-ietf-ipngwg-unicast-addr-fmt-02.txt
        draft-ietf-ipngwg-test-addr-alloc-00.txt

Bob



------------------------------------------------------------------------------
IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/pub/ipng
IPng Home Page:          http://playground.sun.com/pub/ipng/html/ipng-main.html
Direct all administrative requests to majordomo@sunroof.eng.sun.com