Subject: (IPng 6608) Re: fragmentation reassembly

From: [email-masked] (Tim Hartrick)
Date: Fri, 9 Oct 1998 15:03:24 -0700

Steve,

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

I agree that B cannot work.  However, A with internal forwarding mechanisms
which direct fragments to the appropriate per-interface reassembly list
will work.  It requires the same address scope intelligence you cite above
in order to implement it correctly but that intelligence will already need
to exist in order to correctly implement multi-homed and multi-sited node
functionality.  Of course one could argue that such internal forwarding
mechanisms are merely an implementation trick to achieve C.  I would agree
with that argument if pressed.:-)

The point being that I would be unhappy to see any document start laying
out in detail the data structures required to implement IPv6 reassembly.
Specifying the expected result is fine.  Specifying how to implement the
expected result is unnecessary.  There are lots of ways to skin this cat
and we shouldn't start restricting all implementations to a specific style
of cat skinning.

Tim Hartrick
--------------------------------------------------------------------
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:23:37 -0700

> and we shouldn't start restricting all implementations to a specific style

Tim,

Yes, I agree 100%.  I realized the error of my choice of description just
after I posted my message, and you should have seen by now a follow-up
message stating that any implementation is fine, as long as it results
in correct behavior.  The threatened architecture document won't try to
prescribe implementations, but rather describe the architectural model
and intended/consequential semantics in a way that (I hope) will help
implementors to know *what* they need to accomplish, not *how* to
accomplish it.

Steve