(sipp) DRAFT minutes of SIPP working group

[Ross Callon <[e-mail]>]

Enclosed are DRAFT minutes of the SIPP working group last week in
Toronto. Corrections should be send to Bob Hinden, [e-mail]
(Bob will be forwarding the updated minutes for inclusion in the IETF 
proceedings -- I will be out the rest of the week). 

Ross
-----------------------------------------------------------------

SIPP Working Group, Wednesday 4pm

Bob Hinden started by going over the agenda, and introducing the 
recommendation of the IPng area directors from Monday morning. 

Agenda
 - Review agenda
 - Discuss IPng recommendation and future direction
 - SIPP specification (Steve Deering)
 - Addressing Architecture (Bob Hinden)
 - Simple transtion moved to transition working group.
 - Christian's miscellaneous topics
 - Address Allocation Architecture (Yakov)
 - Source Routing (Tony Li -- joint with SDRP working group)
 - Real Time (Chuck Davin)
 - To Do list (assign people to jobs)

IPng AD Recommendations
 - SIPP header format (with extension headers)
 - 16 byte fixed length addresses
 - SIPP security work
 - Simplified transition (SST)
 - ...

Open Areas
 - source routing
 - max payload size and minimum MTU   
 - autoconfiguration and re-addressing
 - authentication and encryption options
 - pseudo-header checksum rules
 - address assignment plan
 - tunneling
 - mobility
 - header compression

The working group agreed that SIPP should disband after this IETF, and we 
should put our effort into the new (and noticeably similar in many regards) 
IPng effort. 

The basic IPng header becomes 40 bytes, with 32 byes of this being source 
and destination addresses. Nothing else has changed except that "payload 
type" has been renamed to be "next header". 

Minor header tweaks have been made to the Fragmentation Header and to the 
Routing Header. 

A new end to end options header has been defined. This is a "bag" of options, 
and allows conveyance of "ignorable" options on end to end basis (strictly 
host to host). This header is for options which, if not understood, should be 
ignored by the destination host. 

Note that current SIPP (and future IPng) header format does not preclude using 
EIDs, although they are not explicitly specified. 

<Dave Clark is to provide text here regarding EIDs and flow ID, which may 
be set by the host as well as by routers and can be used to speed processing.. 

Addresses once again identify interfaces and not nodes. This is related to 
multicast (specifically, an obscure problem which was found in the IS-IS 
working group in Seattle).  There is a request to add the justification / 
description of the problem to the IPng draft. 

Due to the simplification of the transition plan, the C-bit is gone (replaced 
with prefixes). This effects the detailed text of checksumming rules. There is 
also a slight change to UDP checksumming rules. 

An appendix has been added on how to design options. 

Issues:

 - Jumbograms: How large should the upper bound be? How should this be 
encoded (perhaps with a not-quite-straight-linear encoding, such as if first bit 
is 1, implying a greater than 32K packet, then the length is in 8-byte multiples 
rather than one byte multiples). 

 - Minimum MTU: What are the tradeoffs here? 

 - Fancier source routing. Source routing reversibility versus authenticate-
   ability. 

 - Authentication header format and semantics: This is in flux. The IPv4 
   security group is paying attention to the IPng requirements which may result
   in some (probably small) changes to this field. 

 - Changes to pseudoheader checksumming rules (eg, due to SST and/or due 
to authentication header). When we are authenticated strongly, then why should 
we make use of a pseudoheader checksum at all? (the protection against 
changes to the packet provided by a good signature algorithm is much stronger 
than the protection provided by the IP/TCP checksum). 

 - One more change, the name "SIPP" is being changed to "IPng". Or, perhaps 
we could call it IPv6 (pronounced IP Six). The group voted overwhelmingly for 
IP6.

The working group then entertained questions and open discussion of issues:

- What routing are we planning on having? Same as IPv4 (except not BGP, this 
will be replaced by IDRP). 

- Revisit minimum MTU issue: The main reason for this is to allow bigger UDP 
packets (eg, for SNMP and other applications running over UDP over IPng). 
Given that MTU discovery is required by IPng, this implies that the IPng 
conversation between two hosts will use larger packets if and only if the 
subnets can carry it (?Does this help UDP applications much?). IPng over 
localtalk is a reason for smaller MTUs. Also there are some systems in orbit 
which are working with 576 byte MTUs (service calls are extremely expensive 
on satellites -- something about space shuttles and rocket fuel prices here). 

- JumboGrams: Larger MTUs are useful in special very high performance local 
networks. Ultranet optimizes at approximately 200Kbyte packets. Once you hit a 
router, this tradeoff changes to prefer smaller packets (at least much smaller 
than 200Kbytes). As links get faster and more reliable, the optimal size for 
packets increases. Datacommunications are changing. Various forms of video 
and supercomputers result in very large files being sent. We need larger MTUs 
for larger files. 

If you increase the field size then you have made a syntactical change to 
the packet, but this doesn't ensure that you will be able to send those large 
packets over the links. Routers have to control the latency, which implies 
that MTU size will have to take into account the speed of the link and the 
desired maximum delay (per hop). This means that in some cases supercomputers 
may discover a small MTU size due to latency or other considerations for 
other traffic through intermediate hops. 

The maximum MTU size is tied into the design of the hosts. Supercomputers are 
currently designed such that a very large MTU is optimal. 

The problem with MTU is latency, not processing. So, lets look at the rate of 
increase of the speed of the pipes. Eventually we will therefore need large 
packets. 

One suggestion is that a length of zero is an escape to a hop-by-hop option, 
which contains a larger (32-byte) real length field. This was accepted. 

- APIs should be a priority. 

- We need to get a big picture of the work ahead of us, so that we can get our 
hands around it. Vendors have to come up with their own prototype and product 
strategy. 

At this point Scott Bradner, red in face, removed his crying laptop from the 
room to have its diaper changed (or somehow to get it to shut up). 

- Choice of Protocol type / Ethertype issue. From the NHRP (ROLC) working 
group, there is a need to identify protocol / address family in a number of 
protocols (for example, to identify address type in IDRP). Also, a different 
Ethertype / DataLink type would create a clearer dual stack. The problem is 
that this would have an effect on all media. Changing all of the link layer 
types would be a lot of work (with relatively little to show for it). This 
has a widespread effect on implementations. 

Another issue related to link layer protocol types involves the possibility of 
IP code breaking when it sees a packet which the link claims is an IP packet 
but which the IP code doesn't recognize. This could result in a large number 
of apparent checksum errors (but shouldn't happen unless there is some sort 
of configuration error). We should to go out and check whether routers are 
checking the IP version (what are existing routers going to do when they get 
an IPng packet?).

- For SST prefix(es), why not use a prefix which sums to zero under the IPv4 
checksum? Thus, instead of using 0:0:0:0:0:0  and 0:0:0:0:0:1 for prefixes in 
SST, why not use 0:0:0:0:0:0 and 0:0:0:0:0:FFFF?

Source Route Discussion, joint with SDRP (Peter Ford): At this point the SDRP 
working group joined us for a discussion of source routing. 

Hop by hop forwarding is not sufficient as the **ONLY** forwarding method for 
IPng (reasons for alternative include mobility, virtual private nets on top of 
provider infrastructure, provider selection, TOS, Multicast, transit policies, 
etc). We need to go beyond the current hop by hop forwarding paradigm. Source 
routing is part of what is needed for use in some cases. 

Need to be able to specify a routing domain in a source route (or an 
aggregation of some sort, not just a single real router). Need to be able to deal 
with route failures (what if specified next hop cannot be satisfied?).

Strict versus loose indication has to be on a per-hop basis. 

The source route option is variable length up to 32 intermediate hops, with a 
pointer to indicate the current hop, a bit mask to indicate strict versus loose 
for each hop, plus a length field, etc. The source route address list contains 
all addresses (including the final destination, but not the source), so you 
don't do a swap, you just do a write. This also helps if the source route header 
needs to be authenticated (since only the pointer field changes -- and you could 
simply not authenticate this one field). 

There is a concern about the length of addresses in the source routing field (the 
total amount of infomation which needs to be carried in the field causes the limit 
of 32 hops). Concern about amount of "heavy duty header munging" which 
needs to do this in high speed routers. 

There needs to be an option to allow a source routed route setup, with 
subsequent packets forwarded based on flow ID, with most packets not carrying 
the source route. 

There is a question regarding whether the source route can be added by 
routers (as an alternative to adding it by the source host). Clearly this is 
possible if the router encapsulates in a new IPng header, and uses a source 
routing header in the encapsulating IPng packet header. There is some interest 
in doing this without adding an additional IPng header in order to save bits, 
particularly if multiple routers at different levels of the hierarchy have to add 
source routes (at different levels). 

The co-chairs of the SDRP working group are willing to accept the ownership of 
the source routing header. This implies that source routing will be in a separate 
document. However, this is so important that it is important that using a different 
document does NOT imply a lowering of the importance of the header. 

SIPP, continued Thursday morning 9:45am

The IPng Mailing List has been set up as: [e-mail]
To join, send an email message to: [e-mail]
with "subscribe ip-ng" in the text of the message

We discussed the addressing architecture internet-draft:
 
Changes from last version:
	- remove c-bit
	- extended addresses removed
	- source route reversal rules moved to main SIPP specification
	- address types defined
	- removed text for binding addresses to specific interfaces

Basic format for writting addresses in text: 
	- twobytesinhex:twobytesinhex:etc:etc:etc:etc:etc:etc
	- can compress leading zeros
	- can compress middle zeroes (only one set thereof)
	- IPv4 format replaces the last 32 bits (two * two bytes) with ipv4
          dotted decimal notation

Currently assigned address types:
	00		reserved
	01		provider based unicast
	10		geographic
	110		reserved
	1110 00		NSAPs
	1110 01		reserved
	1110 10		reserved
	1110 11		IPX allocation
	1111 00		reserved
	1111 10		reserved
	1111 110	reserved	
	1111 1110	local use
	1111 1111	multicast

It has been suggested to move some of the allocated values together, in order 
to allow the reserved blocks to be contiguous in more cases. For example, the 
NSAP allocation and the IPX allocation might be moved to be contiguous. 

Cluster addresses are a specific form of one of the other types of addresses. 
For example, some cluster addresses might correspond to provider based unicast. 
Currently, there is no allocation for anycast. However, if (when) someone 
figures out how to do anycast, there is plenty of space left to allow this to 
be added. 

Brian Carpenter has a proposal regarding how to map NSAPs into this space. 
This is still evolving. There is still some uncertainty regarding how this 
will actually be used. Until we know what the use is, it is hard to determine 
precisely whether the mapping is complete. One important use which has been 
identified is to allow existing address allocation plans to be used for IPng. 

A complete mapping is not possible into less than 20 bytes. The important thing 
is the logical mapping (to make sure that the necessary information is mapped), 
not the exact syntax. 

Space is reserved for IPX, but the details have not been worked out yet. 

It would be highly desireable to have a convergence of multiple network layer 
protocols to IPng. For example, to run OSI applications over IPng. This might be 
done via some update to RFC 1006, or in a more straightforward and efficient 
way by running OSI application over TP4 over IPng. Some work should be 
done on this (but this is outside of the scope of an IPng addresing discussion). 

The working group discussed the reverse mapping from address to names via 
DNS. Does this have to be based on 16-bit boundaries, 8-bit boundaries, nibble 
boundaries, or otherwise? While the written text format has the ":" delimeters 
on 16-bit boundaries, the hexadecimal digits are obviously specified on nibble 
boundaries. Christian Huitema has the action item to write up a proposed 
resolution to this issue. 

Bob Hinden gave two examples of how addresses might be assigned (on LANs 
and on point to point links). It is important to remember that these are only 
EXAMPLEs, and other formats ARE ALLOWED. 

Bob illustrated how unicast provider-based addresses may be autoconfigured. 
This uses a 48-bit "magic cookie" which is assigned to the host (while it is 
possible that this may be bit-for-bit identical with mac addresses for 
administrative ease, it is essential that this must not be required to be a mac nor 
a subnet address). The 48-bit magic cookie is appended to a "m" bit long subnet 
ID plus an "n" bit long subscriber prefix (such that 48+m+n comes out to 8*16 
bits). The subnet ID may itself be substructured, as may the subscriber ID. 

For PPP links with only two ends, the subscriber prefix plus subnet ID may be 
longer, possibly leaving only 2 bits for the node ID on a point to point link (2 
bits rather than one so that a value can be assigned to the wire itself). 

Other types of links, such as multi-drop links, may have different lengths for the 
node ID field. 

Steve provided another example. THIS IS AN EXAMPLE, DO NOT ASSUME 
THAT THIS IS THE ONLY WAY TO DO THINGS. In assigning fields, it is useful 
to leave unassigned bits in the right places to allow future growth. It is pointed 
out that drawing pictures tends to make people jump to unwarranted 
interpretations of the picture. 

Autoconfiguration / autoaddressing for low end (possibly stub) routers was 
pointed out as an important thing. Proposals on how to do this are welcome.

Private "subscriber" networks with on the order of 1,000,000 nodes must be 
allowed (a gentleman from a high-tech-oriented large fortune 100 company 
pointed this out, quite correctly). 

The discussion today is of a provider based scheme. This implies that when you 
change your provider, you also change your addresses. However, it is important 
that this does not require a change to the local address allocation scheme used 
for assigning the "middle" and low order part of the address within a site. Also, 
end systems will autoconfigure the change to the (high order part of) address. 
Autoconfiguration of stub routers and/or small subnets is also important. 
however, some part of the worldwide Internet will need to be configured (we 
can't autoconfigure everything).

Christian Huitema proposed that, rather than fitting IPv4 into IPng addresses at 
the low order 32 bits, why not do it in the middle of the address? This allows 
IPv4 addresse to be a seed for the IPng addressing scheme. One possible 
reason for NOT doing this is that this could lead to uncareful address allocation. 
Current IPv4 addresses are known to be poorly allocated. There seemed to be 
a general agreement that this was sufficient reason to *not* encourage IPng 
address assignments to be based on existing IPv4 address assignments. 

The proposal is that the minimum allocation to any subscriber is 64 bits. 
However, very large subscribers (example of Boeing was mentioned) may get 
larger allocations (ie, a shorter prefix means "this is Boeing", Boeing then gets 
more than 64 bits to play with). There needs to be some standard for how long a 
prefix large subscribers get, so that if they change providers (or have multiple 
providers at once) they get the same length prefix from each. GM was pointed 
out as another clear example of a big network what might want more than a 64 
bit assignment. It was suggested that the big guys are very much like providers 
(perhaps the real issue comes in middle sized guys, and distinguishing these 
from the big guys). 

One comment suggested that it is desireable to *not* change addresses when 
you change providers. Somehow it was suggested that variable length 
addresses may help here, although it was not clear how. 

Local use addresses are provided for in this address hierarchy (prefix of 
11111110). It is recommended that sites using local addresses start assigning 
the address bits from the right, with fill of zeroes from the left. This allows 
them to change the high order part of the addess when they later hook up to the 
Internet. On the other hand, there may be some systems where we know for 
sure that they will stay local (example of an aircraft carrier was given by 
someone who actually does have a lot of aircraft carriers -- not purchased with 
personal funds). These could use any address from the local space -- there is 
no particular reason to assign from the right in the case that we know that the 
system will always be only local.

This group is not commenting on the desireability of local addresses. Rather we 
are providing the possibility of local addresses for those folks who think that 
they will be useful.

A low order suffix of all zeroes is used for cluster addresses. 

A local loop back address is defined. This is the local address with the low order 
one bit set to one, and the rest set to zero (address FE00:0:0:0:0:0:0:1). The 
cluster label for this would appear to be FE00:0:0:0:0:0:0:0, although some of us 
were unclear what a cluster loopback address would mean.

An unspecified address of 0:0:0:0:0:0:0:0: is defined. This is used where you 
don't know what an address is. For example, this may be used as a source 
address for a system which is sending a packet but doesn't yet know its own 
address. 

There was a question regarding why the loopback address is from a different 
block than the unspecified address. This means that two blocks have been cut 
into. 

Multicast adddress (starts with 11111111) has flags and scope. Details are 
defined in the spec. 

Question: Will we have multi-subnet broadcast addresses? Answer, there is no 
broadcast here, only multicast (you should never send to everyone, rather you 
should send to the right "lots of folks" multicast address). In some cases you 
will need to map IPng multicast onto LAN subnet broadcast, since some systems 
receive LAN broadcast more efficiently than LAN multicast. Some work on 
multicast addresses is still needed. 

Yakov gave a presentation on: Architecture for SIPP-16 Address Allocation (ie, 
the relationship between addressing and routing). 

This document provides guidelines. This is pretty much based on CIDR (ie, 
based on NSAP guidelines, based on much earlier work on hierarchical routing 
--  this is not a new idea but it works). This is based on what is currently 
deployed, which therefore does not require any drastic change from what we 
are doing. 

The set of administrative requirements for obtaining and allocations IPng 
addresses are not discussed. This is not a specific plan for address assignment, 
nor does it deal with embedding address space from other protocols, nor 
multicast, ... The technical aspects of address allocation and the implications 
on routing are discussed in this document. 

The benefits of encoding *some* topological information in addresses is 
discussed. The need for additional levels of hierarchy, etc..

Hierarchical routing: Scaling requires that we achieve some level of information 
abstraction. Within a single-homed leaf domain: This implies that we give the 
domain a contiguous block of addresses abstracted into a single address prefix. 
This is preferably from a prefix assigned by the direct provider.

Providers should have relatively large contiguous block, and give sub-blocks to 
customers. If you want to separate "R&E" from "commercial", you can have the 
provider have two relatively large sub-blocks. 

Question: When we change providers, do we cut a hole in the CIDR-allocations, 
or to we require re-addressing. It is desireable to make it as easy as possible 
to renumber, thereby allowing CIDR-holes to be corrected as much as possible. 
This does not require that we *always* renumber however.

It was pointed out that embedding policy (eg, R&E versus commercial) in policy 
is a bad thing. This could explode, or become uselessly inadequate. Yakov, 
Steve, some other speakers, and the minute taker were in agreement on this. 
There is a problem that while it may make sense to some folks (US 
Government) to split folks into two particular categories, it may make sense to 
other folks (other governments or some large commercial companies) to split 
folks into different sets of categories. AUPs (appropriate use policies) will 
better be addressed by proper policy based routing capabilities, such as may be 
provided by SDRP. 

Multi-homed domains are harder to handle. There is no one correct solution. 
The document points out four possible solutions, any of which may be correct in 
any one particular situation. Thus, it is important to understand the various 
solutions in order to determine which should be used in any one case. 

Continental aggregation deals with large blobs of the topology.l This is 
anticipated as useful to help contain entropy (if changing providers results in 
entropy within one continent, this entropy can be contained). This could also be 
useful for  multi-homed subscribers which are multi-homed within a single 
continent. 

Summary: The ability of the Internet to grow depends upon the ability of routing 
to scale. This requires the use of routing data abstraction, based on using 
addresses which reflect the topology. We recommend provider-based 
addresses. 

We could start experimenting with geographic addresses, for example for multi-
homed sites which happen to be topologically "close" to one of the FIX's (there 
are some examples of this). 

Maximum aggregation is not actually needed. For example, there does not 
need to be *only* six address prefixes at the top level (one per continent, 
probably minus Antartica). It is sufficient to have a few hundred or a few 
thousand at the top. On the other hand, if you shoot for maximum aggregation, 
and assign addresses to that maximum aggregation is possible, this doesn't 
mean that you have to use it. The important thing is that when you allocate the 
addresses you need to shoot for aggregation. 

It must be possible to receive address allocation without connecting to a public 
Internet.

Embedding IP addresses in IPng addresses, and NSAP addresses in IPng 
addresses, and IPX addresses in IPng addresses, may lead to an unroutable 
(or at least hard to route) network. Thus we have to get away from old bad 
address assignments to a new more topological more scalable / routeable 
address assignment. It may be that some bad addresses may give you the right 
to run IPng locally, but *not* give you the right to have people be capable of 
routing data to you. 

Education is essential. This will be an ongoing process. 

Last Topic: Generation of a TODO list:
	- source routing
	- max payload 
	- minimum MTU
	- autoconfiguration and readdressing
	- authenticatioin and encryption
	- pseudo-header checksums
	- address assignment

We need to assign names to documents. 
	- address assignment: take current CIDR assignments and IPng-ize 
	                                (Yakov)
	- address CIDR-stuff		(Yakov)
	- base IPng spec 		(Steve Deering)
	- address something	 	(Bob Hinden)
	- DNS 				(Christian H)
	- ICMP/IGMP			(Deering and Conta)
	- MIB				(Kayce)
	- neighbor discovery, Address Resolution    (Bill Simpson, Conta)
	- NSAP mapping			(Brian Carpenter, Jim Bound)
	- APIs				(Bob Gilligan and Jim Bound)
	- security			(Ran Atkinson)
	- compression			(Bill Simpson)
	- FTP	(Foobar)		(Piscitello)
	- SNMP (not MIB)			
	- OSPF
	- IDRP				(IDRP Working Group)
	- IS-IS
	- RIP

Overall consistency is the responsibility of the IPng working group chairs, and 
Dave Clark as official IPng Reviewer. 


 ------------------------------------------------------------------------------
IETF SIPP Working Group - Archives:  parcftp.xerox.com:/pub/sipp
Unsubscribe:	unsubscribe sipp		(as message body, not subject)
Direct all administrative requests to [e-mail]