Subject: (IPng 6603) fragmentation reassembly

From: Richard Draves <[email-masked]>
Date: Fri, 9 Oct 1998 13:46:43 -0700

I was thinking recently about the provision in the spec that "An original
packet is reassembled only from fragment packets that have the same Source
Address, Destination Address, and Fragment Identification." In particular, I
realized that since the destination & source addresses might have link-local
or site-local scope, this provision is actually somewhat ambiguous.

(A) If the implementation maintains a data structure of fragments pending
reassembly that is per-interface, then there's no confusion about the scope
of the addresses. But then suppose fragments arrive on different interfaces,
fragments of a packet sent from a global source address to a global-scope
multicast address where the fragments happened to be routed differently.
Shouldn't they be reassembled even though they arrived on different
interfaces?

(B) If the implementation maintains a single data structure of fragments
pending reassembly, then there's the danger of confusing fragments that
really belong to different packets because the addresses involved have
limited scope.

(C) Or the implementation might keep a single data structure, but augment
the source address, destination address, & identification with information
about the interface & site that the fragment arrived on, to be used
depending on the scope of the addresses involved. This makes matching
fragments in the data structure more complicated.

Is it "correct" to use implementation A or B? Or must a correct
implementation use C?

Thanks,
Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Fri, 9 Oct 1998 14:27:15 -0700

> Is it "correct" to use implementation A or B? Or must a correct

Rich,

Certainly, neither A nor B is correct.

  Packets to or from a link local address may be reassembled with
  and only with packets arriving from the same link (possibly from
  different interfaces to that link).

  Packets to or from a site local address, where the other address
  is not link-local, may be reassembled with and only with packets
  arriving from the same site (possibly from different interfaces to
  that site).

There are analogous restrictions on reassembling packets to scoped multicast
addresses.

So yes, you need a more sophisticated data structure than either one global
reassembly list or one list per interface.  What you need is one reassembly
list for each attached "scope instance" (I need to think of a better term
for this), where your scope instances are:

	- the global-scope instance
	- site instances for each site to which you are attached
	- link instances for each link to which you are attached

plus instances for the various multicast scopes other than link, site, and
global.

I really need to get my "IPv6 architecture" document done one of these days....

Steve

---

From: Paul Dyke <[email-masked]>
Date: Fri, 9 Oct 1998 14:37:24 -0700 (PDT)

> Shouldn't they be reassembled even though they arrived on different

Rich, this should never really happen because a node joins a multicast
group on a specific interface, and multicast routing constructs a path to
the multicast tree.  Packets are then routed based on state in routers
along the path to the receiver.

However, another interesting case regarding fragmentation involves mobile
IP. Since a mobile node's address changes as it moves about, if the change
of address occurs while sending fragmented packets, the source address of
some of the packets would be different from other packets, and
reconstruction would break. Note that mobile IP defines a Home Address
destination option, but technically this is part of the fragmentable part
of the original packet. I suppose that a sender could place the home
address option in the unfragmentable part of the packet, but I don't think
this is what the mobile IP authors intended. 

Paul

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 09 Oct 1998 16:45:55 -0500

> What you need is one reassembly list for each attached "scope
> instance" (I need to think of a better term for this),

The word "scope" is groaning under its burden of meaning already.
While discussing router renumbering with an implementor, I identified
three completely different ones:

	1. For the domain of validity and uniqueness of a unicast
	   address there are three scopes: link-local, site-local and
	   global. 

	2. For the derivation of an interface identifier there are
	   two scopes: global and local.

	3. For the bounds of a set of nodes receiving a multicast-
	   addressed packet there are potentially 16 scopes, of which
	   five are defined: node-local, link-local, site-local,
	   organization-local and global.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Fri, 9 Oct 1998 15:05:59 -0700

Floowing up on my own message:

At 2:27 PM -0700 10/9/98, Steve Deering wrote:
> What you need is one reassembly list for each attached "scope instance"...

I didn't mean to imply that keeping a separate reassembly list for each
scope instance was the only way to implement it.  Anything that achieves
the same result is OK of course.  For example, you could derive the
scope instance at the time of arrival (based on the arrival interface
and the minimum scope of the fragment's source & destination addresses)
and store an identifier for that instance with the fragment, in one
node-wide list (which was your solution C, I think), or you could compute
the scope instance for a stored fragment at the point in time where you
check to see if it can be reassembled with a newly-arrived fragment
(assuming stored fragments are tagged with arrival interface identifiers).

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 9 Oct 1998 16:29:32 -0700 (PDT)

> Certainly, neither A nor B is correct.

Steve,

Alternative A (per interface reassembly) would be correct if an 
implementation followed the "strong end-system model".

Are you asserting that the IPv6 archiecture uses/requires the
"weak ES model"? (I haven't seen such a requirement stated before - it would
be good if we can nail this down in the architecture.)

   Erik

---

From: Steve Deering <[email-masked]>
Date: Fri, 9 Oct 1998 17:13:47 -0700

> implementation followed the "strong end-system model".

I'm not sure that's entirely true, because of anycast addresses (see
previous message).

> be good if we can nail this down in the architecture.)

There are actually two separable properties that the strong/weak model for
multihomed hosts pertains to:

	(1) may a host originate a packet who source address does not
	    belong to the originating interface? (strong: NO, weak: YES)

	(2) may a host accept a packet destined to one of its own
	    addresses if the arrival interface is not the one to which
	    that address belongs?  (strong: NO, weak: YES)

With regard to (1), I think we need to accept the weak model to allow,
for example, a host attached to the receive end of a unidirectional link
(like a direct-broadcast satellite channel) to answer a "ping" addressed
to that interface.  In that case, the source address of the ping reply
needs to be the address of the arrival interface, but because that
interface is unidirectional, the reply has to originate on a different
interface.  On the other hand, a problem with the weak model for this
property is that it breaks ICMP Redirects, so one wants to discourage
"exploiting the weakness".  Therefore, with regard to property (1), I
think the IPv6 model should be: "the source address SHOULD belong to
the originating interface", rather than "MUST belong".

With regard to (2), which I think is the basis of your question, the arrival
of a packet at an end host on an interface other than one belonging to the
destination address indicates either an error in the routing system
(including Neighbor Discovery as part of the routing system), or
manual configuration of a neighbor to force delivery to the "wrong"
interface.  I don't feel it is necessary to insist on the strong model
here, because violation either won't happen or will happen because some
network administrator configured to happen.

So, as one who used to argue vigorously for the strong model, I have
now "converted" to support the weak model, FOR UNICAST.  Multicast, on the
other hand, MUST use the strong model, but that's a subject for another
message, someday...

Steve
(now departing for the weekend -- offline till Sunday night)

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Oct 1998 22:25:45 +1000

Date:        Fri, 9 Oct 1998 17:13:47 -0700
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v03110714b2445078ca9d@[171.69.199.124]>

  | With regard to (1), I think we need to accept the weak model to allow,
  | for example, a host attached to the receive end of a unidirectional link

You don't need unidirectional links to see this need.   It is entirely
reasonable for the only known route from a multihomed host to many
destinations (including 'default') be out one particular interface.  In
fact, I'd think that's a common case.   When a node is replying to
an incoming request, it needs to send out the interface which it believes
will get the packet to the destination - regardless of what the source
address happens to be.   It also normally doesn't get to choose the source
address, that is generally constrained by the destination address of the
packet that was received.  The interface the packet was received over need
also have no relationship with the one it will reply through.

Ever expecting that the source address of a packet will be related to the
interface through which the packet is sent is folly.   It is possible to
construct administrative regimes where this will be true - but that's for
the administrator of the system not for the implementor of its software.
The software must have no restrictions in this area (nb: "no restrictions",
which does not mean that the default source address, where there is no reason
to use any particular one, should not be that of the outgoing interface).

  | With regard to (2),  [...]
  | I don't feel it is necessary to insist on the strong model here,

I agree, but at least this one is one where an implementation wouldn't be
terminally broken by this choice (unlike the previous one).   An implementation
that implements the strong model for packet reception will limit the 
administrator's choices as to how the implementation is deployed, though
in most cases, the admin will probably never see the difference.   That is,
I don't see that we need to prohibit the strong model (for packet reception)
either, which would be the more likely question, not whether we need to
insist upon it.

kre

---

From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[email-masked]>
Date: Sun, 11 Oct 1998 10:38:10 -0400

Steve,

>I'm not sure that's entirely true, because of anycast addresses (see

The anycast model by definition is the weak model IMO.  Also is it time
to show anycast addresses are in fact needed by hosts or at least server
machines for networking?

>multihomed hosts pertains to:

First nothing in anyones vision of what the IPv6 architecture is or is
not should break implementations.  Steve whats up with your document I
assume your doing some kind of FAQ?  I am building one too and it will
go to the masses soon!!!! 

I would say the default is strong but we cannot disallow the weak.  

I would say a host must accept a packet if it has that address within
its node.  

So I believe the entire discussion is purely academic and customers  
require that a product must permit both behaviors to be flexible for 
the consumer.

Where it becomes relevant is to resolve the issues Richard brought up
about fragement/reassembly.  But that was because of those darn scopes
again.  But here the academic discussion can be useful.  

Lets be careful here what this discussion is depicting and not let it be
misleading that we will try to nail down a weak or strong model
consensus will never happen in the IETF community.  It is like EIDs vs
Locators discussion.

>the originating interface", rather than "MUST belong".

I agree with you on this one.  Where are these SHOULDs and MUSTs going
to exist?  Again my question to you what is this document?  Please
respond to this as if your going to build a spec that affects the very
nature of IPv6 implementations then I would like to know that and I am
sure other implementors will to?  I will say more if the answer is yes?

>other hand, MUST use the strong model, but that's a subject for another

At the end of the day we will support what the customer wants as both
models are needed depending on the reqs of the network for the customer.

But the point of all of this is to address what Richard found from
implementing frag/reassem code and testing it.  The answer is if you can
get it work with our scoped addresses do so.  If you can't then tell the
WG.  Other than that it is not an IETF issue I can see at this point but
an implementation issue for the IPv6 architecture which permits an
uncanny scoping of addresses which will clearly be a nightmare for
implementation deployment.

/jim