IPng Directorate Retreat, BigTen Conference Center, Chicago Il. May 19, 1994 Mark K's notes from the retreat Guests have left the room, directorate forms agenda. Agenda: 1. Round table/review highlights: 1 min per person with guests, list 3-4 major "review" topics for discussion during this retreat. 2. Routing and Addressing (today). 3. Plug and Play (autoconfiguration) 4. Transition aspects related to routing architecture: the way the mechanisms of transition support renumbering. (transition tomorrow) Transition as a focus for Toronto. Monday morning: Alison and Scott for 2 hours in plenary, will make recommendation! and lead discussion. Next, open directorate meeting. IESG will vote whether to support recommendation, during the week. Mark is taking minutes, Ross will contribute. Reviews have been submitted (not all of them though) from directorate members. Scott has not posted them back to the list. We will not complete reviews these 2 days. The next phase of the directorate is to look at final comments on proposals. Everyone will have a chance to read everyone else's reviews. Reviews will be kept confidential on request. What do we expect to achieve these 2 days (deliverable)? Identify strengths and weaknesses of proposals to have basis for evaluating them. Allow for unification of ideas in proposals if possible. If needed, an expert will be asked to clarify and explain technical material. Who is routing and addressing expert for SIPP? Who is the expert who can answer this? Steve Deering and Paul Francis. There are strengths and weaknesses to various degrees for each proposal. If something is fatally broken, identify as so. These points should come out in the review points. Each invited expert should state up front what their expertise is. A draft recommendation will be circulated to the directorate in June. Scott and Allison will meet in Cambridge to finalize this. --- The guests have returned. Introductions. Invited guests should state their field of expertise. Scott Bradner Allison Mankin Erik Nordmark, Sun, SIPP working group, implementations, transition Robert Ullman, Lotus Development, CATNIP Steve Bellovin, AT&T Bell Labs, Security Dave Piscitello, Core Competence, TUBA transition, CLNP standardization Mark Knopper, TUBA co-chair Dave Katz, cisco, TUBA expert, OSI routing protocols, implementation issues wrt routers Steve Deering, xerox, the S in SIPP Bob Gilligan, Sun, SIPP transition, design and implementation Ran Atkinson, NRL, SIPP for BSD, expert on security proposals for SIPP. Frank Kastenholtz, FTP Software Lixia Xhang, Xerox PARC Sue Thomsen, SIPP autoconfig Jay Allard, Microsoft John Curran, BBN Peter Ford, Tuba co-chair, implementation, transition, Internet architecture/reality, NSFNET consultant Yakov Rekhter, TJ Watson at IBM, routing, CLNP, IP, mobility, Internet architecture/reality, routing arbiter for NSFNET Paul Francis, NTT, P of SIPP Greg Minshall, novell Tony Li, cisco, lofted the TURNIPP proposal, CIDR architecture Dino Farranacci, cisco, implementation of routing protocols, IP multicast, TCP/IP and OSI network layer, TUBA implementation Ross Callon, wellfleet, routing protocols and addressing, DECnet transition Review points: Ross: what is broken and will not work. IPAE mapping, translation. Some concerns about SIPP addressing but not as critical. Dino: address size needs to be sufficiently large for unanticipated growth (general concern), global EIDs--need to make decision on whether part of or different than locator. Routing protocols, longest match paradigm, hierarchical. IPv4 addresses carried by IPng is complex. Encapsulate or translate is ok, but routing architecture becomes complicated. Tuba is good because of CLNP, if not CLNP it is a new proposal. It is important to use existing infrastructure. CATNIP - insufficient documentation, how FCIs are propagated between routers, how routing protocols are used, not enough to implement now. SIPP - need to eliminate or simplify IPAE. IPAE is fatal. Tony: addresing and routing on SIPP is concern. Greg: addresses vs. source routes with SIPP, autoconfiguration issues with SIPP, max segment lifetime with SIPP, TUBA alignment of transport header, TUBA CLNP error responses, what is a flow, what should maximum payload size be. Addressing, alignment and autoconfig is fatal. Greg dismisses CATNIP. What does "fatal" mean? Cannot be made to work in its current form. Paul: dismisses CATNIP due to lack of documentation, also from political perspective. No fatal flaws in any of the proposals, can all be made to work. CLNP is weak in routing capabilities, eg. provider selection. Transition: difficulties with IPAE. Yakov: semantics overload is concern. Send as few bits as possible in address. Address and routing header in SIPP has semantics overload. Complexity of transition in SIPP is problem - piecemeal transition among uncooperative parties. Need common ground for migration from other protocols including IPX. Peter: agree with semantic overload problem, makes system terribly brittle, is serious design flaw. This concern encompasses all proposals. Transition plan is independent of protocol. IPAE is mainly ok but the part requiring coordination is very problematic. Extensibility and addressing is major topic for this meeting. Selection as a process is tragically flawed. The outcome of this meeting should be broad consensus to build IPng. Cut the crap. John: Agree on single design team with all thrusters going. Everyone should work on same proposal. EIDs and transport independence at network layer is a problem with all proposals. Need to come to agreement on this. Exclude CATNIP from reviews, since it does not handle autoconfiguration and a list of items that are required on technical criteria. IPAE fails architectural simplicity, cooperative anarchy tests, can't meet criteria. Operational impacts of SIPP create new paradigms, are significant problems but not insurmountable. Jay Allard: IPv4 with DHCP allows arbitrary payloads. Need autoconfiguration not autoaddressing in IPng. Most implementations of TUBA will require dual stack. Also SIPP will probably require dual stack. SIPP 64 bit addressing scheme is probably not sufficient. DHCP and DNS proposals for SIPP are not very clear, need concrete examples. NSAP addressing is ok. NSAP addresses in SIPP header is ok. APIs should be added to requirements document. Eric F.: IPng is high risk, need to lower risk. Conversion between protocol families should be requirment. Provider based addressing is flawed. NSAPs ISO8348ad2 are too broad and will not aggregate, therefore if TUBA is selected we need a subset of those fields. SIPP as defined cannot meet Boeing's addressing needs. Sue: global EID. Lixia: Authentication and accounting at network level. Research has not been done yet, but need is coming for these functions. Cost of TUBA's dual-stack ONLY transition plan is problematic; BOTH dual-stack and translations are needed. In addition, CATNIP has no transition plan, no routing design, and is not sufficiently specified to be evaluated. Frank: Architectural and future perspective that each proposal has presented. Routing and addressing, network service models. CATNIP proposals not complete. Ran Atkinson: CATNIP not complete. Transition is separable from IPng protocol. Exploring SIPP without IPAE. Need mechanism for authentication which does not rely on confidentiality at network layer. TCP/IP over 2400bps HF radio works now, IPng needs to work. Mobile IP working group wants to put in more users per bit of bandwidth, not just military. Bob Gilligan: TUBA transition is too hard for end-users and system administrators. Host can't use TUBA until all routers are converted. Host needs 2 addresses, requires coordination between host and network sysadmins. Doesn't allow for eventual introduction of TUBA-only host. TUBA minimum header is too big. Steve Deering: reassembly at intermediate routers (CATnip problem), max packet size is 2**32. Scalability of CATNIP routing. These are fatal. Technical issue with CLNP: multicast design complexity and redundancy. Dave Katz: concern with addressing and EIDs. Are EIDs really flat? This is of primary importance. What goes where and what are semantics. Is this paradigm shift? Autoconfiguration and first hop host routing issues with respect to SIPP - extensibility and transition for other protocol stacks. Forwarding speed issues, design tradeoffs on host performance vs. router performance (are they at odds?). How to get away from IPv4 addresses. Business case/user motivations for doing any of this (possibly fatal). Mark: TUBA understood, IPAE fatal, heirarchical address scales into other protocol headers, large customers Dave P.: satellites, planes, every device in house, number recyclability, 64-bit addresses work only if recycling happens. IPng aversion syndrome with regard to renumbering. Renumbering should be easy for customers. Authentication and accounting are very important. Which packet we choose is of secondary issue. Steve Bellovin: some issues separate from choice betwen sipp, tuba, to lesser extent catnip. All issues that have to be resolved are at higher level. This includes transition. IPAE does not work, is a non-starter. Dual-stack and translators are needed. EIDs: don't know what they are any more. SIPP addressing is largely unknown. TUBA - never will converge with OSI. Death of TCP is getting further away. Is CLNP worthwhile in and of itself? Are we going to end up with two different routing mechanisms for two different parts of the NSAP space. Rob: TUBA and SIPP both change definition of TCP and UDP checksums. This breaks translation. IPAE is fatal, SIPP would be better off without it. When SIPP was 64-bit addressing it was flawed. If variable length, should be NSAPs. Need political and legal (governmental) authority for addresses. IANA needs delegated authority from ISO. Security proposals should be orthogonal to network layer. Changes to DNS requires administrative work, requires retraining on addressing structure. Payload and payload identifier size is too small in SIPP. SIPP: no payoff in eventual reduction in number of protocols. Lotus will not deploy SIPP. Erik Nordmark: TUBA problems: Need piecemeal transition that works. Route scaling during transition. ARPANET long leader hack for NCP. Size of address space in NCP for the IMPs expanded. Old Hosts needed to talk to new hosts. Applications specify short address, host adds prefix. ARPANET was small and non-production though. -break- Jim Bound will call in. His points are: variable address increases the cost of development and performance on a host. That cost needs to be justified meaning why won't a fixed 16byte address work EID should be a fixed size transport identifying address, but the routing sequence could be variable as an IPv4 source route. the mechanisms to support this further in the future were in the SIPP ROAD architecture, and that he proved that from a transport perspective with actual running code. thinks technically carrying around source locators in the DNS record identified by a globally unique fixed identifying address would work technically on a host without great cost. Autoconfiguration is a critical carrot for folks to migrate or even use IPng and we had to be delivered with first shipments of IPng into the market. --- At last directorate meeting in Seattle, we agreed to separate evaluation of transition plan from evaluation of protocols. We will table issue of transition for now. Discussion: can't separate them for selection/recommendation process. We have to make decisions about transition before deployment. We will table until tomorrow. Routing and addressing topic - this afternoon. EIDs is a major topic: can we get a resolution? Description of use of routing prefixes for routing architecture of the future. How do addresses get extended? Size. Are there fatal addressing problems in any proposals? Greg: alignment is fatal. Dave P: Is it the size of address or encoding in packet? It is encoding and alignment (Greg), it is size (Dave). Link layer has alignment problems, because of multiple stacks. If you can beat the link layer into shape, and the net layer is aligned, then you can align the transport header. Peter: this is semantic overloading issue. Need 32 or 64 bit alignment. Jim: address should be aligned on 32 bit boundaries, with SIPP, doesn't want variable length addresses. John: routing header and address sequence for SIPP qualifies. Dino: can SIPP 8-byte address be optimized? This is EID vs. locator discussion. If internet header is aligned, then transport header should be aligned. The network layer should not prevent transport layer header alignment. Padding can be used to allow this. A CLNP profile for TUBA could allow this. -------- Dave Piscitello's notes here -------- Eric F.: The Boeing problem. 64 bits not enough space for internal administrative needs to provide the internal aggregation of our possible medium term-sized networks and that it (in his opinion) will not scale to meet the needs of the Internet community. . 2 class A's, 28 class B's plus class C's, all being used by Boeing. Yakov: 1. efficiency lost with hierarchical addressing 2. address administration harder with hierarchical addressing Dave P: can addresses be reclaimed? Cable, electric, telephone companies providing internet service, how can we provide enough addresses? Tony: also problem with granularity of the hierarchy. Byte boundaries, nibble boundaries. Can we get users to go to hex addresses? John: how to get administrators to understand address plan to administer their 90000 hosts? This problem causes people to do private networks, can't train and explain to people. It's not only because there are not enough addresses. -lunch- Round table: EIDs - yes/no, globally unique?, structured? what are they used for? How will they be used? EIDs - what are intended uses? Bellovin-organizationally structured EID works for security purposes. EID is a public key? Who issued it? It is not tremendously useful because of this. Ross: reason: stamp device with identifier, but stamp the "where" independently when it sends a packet (high order identifier). If EIDs are used in this way, the address either includes the EID or does not go all the way to the host (goes to the subnet or to the area). EID is a quantity that could be 64 bits, assigned to the host at birth, stays with it wherever the host goes. EID is globally unique. Address autoconfiguration should be easier. If addresses are substantially bigger than is needed for EID (eg larger than 64 bits), can use multiple locators but not whole addresses. EID is dense, but locator is sparse. Paul: EIDs should be used for serverless autoconfiguration. EID is given to machine at birth (like 802 numbers, assigned via vendors). This implies EIDs are globally unique, mostly so that it is globally unique on the wire. As long as you have EID, it is also useful for other things. Such as location-independent cookie to identify other machine. This alone does not justify EIDs. Yakov: Semantic overload. IPv4--4 byte address with 2 purposes: 1) endpoint for transport connection, 2) encoded hierarchical address for routing. Learn something from history, this created a fair amount of problems. Flat routing (single area) vs. longest prefix match (CIDR). What happens at lowest level is different than what happens at highest levels in hierarchy. For flat routing, use EID. For hierarchical routing, use locator. Example of real problem because of semantic overload. John: network level identifiers are subject to change because of mobility, autoconfiguration, multiple connections on two different network realms, like a supercomputer. Transport identification and above will remain constant throughout mobile addressing process. (Steve Deering: can do the same thing with IPv4 now.) Dino: for performance, hosts want fixed length addressing, for scaling reasons, routers want variable length addressing. Put host addressing/EID in the fixed length portion, put locator in the address portion (variable length). Paul: existence of fixed size identifiers frees application from uttering location info. John: TUNE is not an Internet-Draft/RFC now because of problems noted after first draft. Paul: whether organizationally assigned EID or vendor assigned EID is crucial. EID Uses 1. address autoconfig 2. mobility 3. reverse lookup 4. decouple flat vs. hierarchical routing 5. decouple network from transport level identifiers 6. host gets fixed length, router gets variable length 7. endpoint of transport layer - not 1-1 with machine but process Characteristics 1. globally unique 2. universally stamped on things 3. assignment through delegation hierarchy Rob: Can be more than one EID on a machine (it's a process). Vendor stamped number on a machine is not the same thing as EID. Dave: earlier paper on TUBA sysids. Yakov: With EID you can do flat routing, results in unambiguous routing. Does not scale of course. Bellovin: in xns, host id is separate from net number. Deering: Identifier for net layer entity (Like CLNP RNETS), identifies an IP engine. Ran: secret/topsecret/classified/etc. hosts. In single box, vendor doesn't know that it will be used as a multilevel security platform. Vendor stamped identifier in the box would need either multiple identifiers or host would use separate field to identify process. Paul: identifier is generally box-unique (IP number today). No, need more. John: what an EID is. When a frame arrives on a machine, goes to the IP stack, then above to TCP or UDP. But at the transport layer the whole datagram is processed at that level. TCP does not really need to get that information, should get a TCP-PDU with fixed length EID in it. This has huge implications. Ross: IPng will not work without autoconfiguration. But there are problems with server based autoconfiguration. Deering: possibilities 1. full locator separate from ID DNS mapping is painful. 2. Location is whole address, ID is rightmost portion. Location includes ID. ID portion is globally unique. 3. Locator and ID are equivalent, the whole address Use whole locator as identifier. TUBA currently defines this. SIPP uses this currently also. IPv4 as well. -break--> TUBA, SIPP meet separately TUBA breakout session: Dino: message from SIPP group, carry 16 byte fixed length addresses in SIPP packet. Much discussion. Ross's Alternative: SIP Fixed (8 byte EID) Dest Pointer | Source Pointer 8 byte quantities for dest location Dest ID 8 byte quantities for source location Source ID Can include NSAP addresses in variable length location fields. -break--> whole group meets again. Which header should we start with? SIPP or CLNP? Problems with SIPP: addressing/fixed/64bit routing header first hop routing SIPP: identifying addresses are the locators. These will also act as transport layer identifying addresses. So SIPP should be amended to explicitly recognize 64 bit EID, and add locator. "Orthogonal but somewhat related." - Dave Katz, )1994 For provider selection or mobility - use SIPP routing header. 64-bit SIPP locator is not big enough to carry 802 address, therefore not amenable to serverless autoconfiguration. Need 2-element SIPP address for serverless autoconfiguration. Paul's tutorial: multicast 11111111 local use 1001 + 12 bits + 48 bit ethernet unicast - cbit + 0000000 + provider id + etc. extended address: 0000+provider id (32 bits) | subscriber id | 4 bits | subnet (12 bits)| 802 address (48 bits) 0000 above is extra for growth. RFC 1219 assignment for provider id. Left 64 bits is locator, right 64 bits is EID. Yakov: in current Internet, we route on absolute addresses. Relative non-unique addresses are not currently understood for routing. Steve's proposal for multiple routing tables is "brittle". Steve: subnet numbers are not globally unique. Rob: why are we doing this? Could be put into one 192-bit place in the spec and be done with it. Ross: 64 bit would be sufficient except for a few issues. Everything except for 64 bits should be globally unique. In normal case you have 2. Greg: want an identifier to locate host. Need to know where this field is within 192-bit field within router or host. Bellovin: simplistic view. Gethostbyname - gives A-record. How many bits come back? What do I pass to gethostbyaddr. Why not just make it 128 byte chunks? Paul: Engineering tradeoff point. Additional addressing info in packet header is good for mobility, etc. Need to grow the packet in some increments. Variable length allows growing in small increments. But preference is fixed size increments. Dino: why not build an address that's small, extend by small increments with variable length. Yakov: source route applications: 1. encode hierarchical addresses 2. provider selection 3. virtual point-point links (tunnel) 4. location information (where I am located now message) 5. route to host's current location Should all of these kinds of applications be forced into single semantics? Unified requirements for IPng - different applications of source route. Dave K: Steve Bellovin. No string of structure, very context sensitive, need to be in right place. Firewall filtering, looking at destination address. It's not in my context. How much is locator, how much is source route. Independent of Tcan you embed a source route'. Paul: filtering is very important. Mobility, provider selection. Semantic overloading argument. 1 mechanism or a lot of mechanism. What comes back from a DNS lookup--in Paul's model would return both 64 bit quantities. Would need all 128-bits to specify firewall filter. Dave K: impossible to source route through a machine that was using a 128 bit address. No delineator that says this 128 bits is a single chunk. John: iconoclastic question. Loose source routes can be used for both provider selection and mobility. These lists can be lists of variable length elements. Is this ok? Paul: agree there are tradeoffs. fixed chunk is cleaner. If half the hosts in the world don't recognize extended addresses, if DNS doesn't do this, if,... then variable length won't work. Yakov: different applications of source route imply different lengths. Deering: always still have the ability to do encapsulation (tunneling). Source routing only makes sense when the source determines the route. Yakov: tunnels, mobility routing info. Strict source routing is different than loose source routing. Source route at the level of providers. Go to X only if X is adjacent to Y. Strict source route: mechanism where if the router isn't immediately adjacent it drops the packet and sends an error mgs. Paul: in SIPP spec, this needs to be fixed: node level source routing with extended addresses doesn't work when system naively reverses the whole thing. Would have to repeat the whole thing. Yakov: every IPng proposal should be matched to at least one routing architecture. Current architectures are Unified and NIMROD. Litmus test for IPng success: can Dave P's dad understand it. Dave K: we've already sold to all of the smart customers. Consensus: SIPP extended addressing using the Route Header was unworkable, and, that 64-bit addresses are too small if you want to do address autoconfiguration with 48-bit IEEE 802 numbers. Peter: why not variable length addressing with hierarchical semantics. We can talk about this after dinner. --- Distributed: "Source Routing with Relative Addressing compared to Conventional Hierarchical Addressing and Source Routing," by Rekhter and Ford. --- Dave P: Short tutorial on NSAPs. NSAPAs - ISO/IEC 8348 - definition RFC 1237 - Internet assignment guidelines RFC 1523 - system IDs for TUBA ITU-TS AFI | ISP | DSP AFI (8 bits, BCD encoding): CCITT X.121 E.163 E.164 Telex F.69 ISO DCC ISO ICD (90 code points, 0-9 reserved) ISO DCC for US is 840 administered by ANSI ISO ICD used for US-GOSIP administered by GSA AD = 4 octets RD = 2 octets DSP: area sysid sel Sysid: 6 octets. Could be 802, embedded IP address, or other code points. Sel: used to identify transport entity, in TUBA the IP protocol number. Prefix=everything to the left of sysid (area). Myth: 20 octets is max. length of address you can put into CLNP packet. Not true. 20 octets is max defined in 8348 but the CLNP protocol can carry more. Implementations--will break if you use more than 20? Is this in conformance suite? Structure of low order part is qualified by high order part. ANSI standardized the DCC format. Can get AAI/org id from ANSI. Steve Deering: is 20 really big enough? Dave: need flexibility to increase it, with variable length mechanism rather than 64 bit chunks. Upper bound is 256 for whole header. Deering: how many formats in use for Internet? AFI 47=ISO ICD GOSIP, AFI 39=ISO DCC US ANSI. Other AFIs not profiled as addresses we use for Internet assignment. How many AFIs in use total? AFI 39 is used by many countries. 47.0004 - OSInet 47.0005 - US govt 47.0006 - US DOD 47.0020 - DECnet IV conversion 39.xxxF (xxx=DCC) 47.0023 - Sweden 47.? - CDPD (Mark will check) How does this lay out a scalable topology for the Internet? It's the same as CIDR. Provider-based hierarchical addressing. Deering: potential for geographic and telephony based addressing using NSAPs. John: good news, no shortage of NSAPs or addressing authorities. ANSI, GOSIP, ICD, etc. What happens when all these get to be routed? Provider-based allocation is required for use of NSAPs, else it is a problem. There has to be some pushback from address authority. Providers will charge for advertising exceptions (holes), or otherwise discourage this. In CIDR, you can get prefix from other than your provider, which causes problems. Yakov: the fact that you can get a net address doesn't mean that it can be routed. There are currently no pressure back mechanisms to ensure good assignment. Dave: not true. Worst case: everyone gets their own org id. In 47.0005 space, US governmental units can get AAIs from Richard Colella. Acquiring address space is often a business decision. 5 offices can obtain space from individual providers, or get their own AFI. Deering: to what degree is full NSAP needed, can it fit into a 16 byte field? John: functionality would be equivalent with 16 bytes. Dave P: agree. Rob: customers will pay for high order bits in their address prefix that don't match their address. --dinner-- Routing and Addressing this evening. Allison: SS7 :):). Flat space for gettin all hosts, using signal transfer points. Separate out of band network for management. Centralized database. Compromise position on routing plan. Variable length plan. Deering: EIDs identify things at these possible layers: IP transport socket process Like service access points in OSI. Tony: field of some number of bits which gets sandwiched underneath the TCP header (not in the network layer header). Mechanism unclear. Greg: some transport protocols have connection identifiers. Prevent checksum problems when location changes. Mobility. Do we want to use Mobile-IP solution in IPng? Combine global id field with autoconfiguration. Possible architectures for convergence: Yakov: develop consensus on needed components FUBAR for IPng API for IPng Decision point: to send an IPng or IPv4 packet, should need only one query to DNS. You get back a new address, using it will get you to the other host somehow (possibly by backing off to IPv4). Currently with TUBA you have to ask for A-records then IPng records. Resolver is only set up to do single type of query right now. You don't put a CLNP address into the DNS until it is connected to the T-BONE. Or have a bit saying it is on the bone. Rob: CATNIP. If we could decide on what network layer addresses look like we would be 98% of the way toward a solution. Conclusions from meeting earlier today. Agenda for tomorrow: cap off routing and addressing - Transition plan Dino's proposal SIPP header source and destination addresses are NSAPs or new address structures with variable length. Peter: what's wrong with TURNIPP? What makes it different than CATNIP? Tony: use NSAPs in 64 bit hunks. Rob: the only technical difference between that and CATNIP is that CATNIP uses hunks of 32 bits. What is wrong with using a variable length address? Paul: you have to limit the size of the address at some point. 16 bytes is ok. Peter: a tcb is already bigger than an mbuf. What would 128 bits not be big enough for that source routing wouldn't compensate for? (Scott) No, just why would you need more than 128 bits? Could map existing prefixes for CLNP into 128 bits. There is a difference between fixed length and an upper bound with variable length. Rob: one byte length indicator even if fixed length is used, will solve a lot of problems. ------------ May 20 Yakov: Unified Routing Requirements for IPng Fundamental requirements of addressing. 1. Needs to scale to practically unlimited size requires hierarchical routing, eg. CIDR addresses are not flat routing protocols are capable of aggregating routing information should not be forced to route along strict hierarchy, ie. should be able to route across lateral links (either private or semi- private). Lateral links are not required to be globally visible links. Deering: this is Kleinrock and Kamoun from 1970. 1a. Hiearchical addresses - requires topology-specific addresses 1b. Provision for non-hierarchical paths 2. No limits on the number of level. No constraings on level's boundaries. Have seen how Boeing is going to organize their network. Should not limit the number of levels in hierarchy. Ipng shouldn't place restrictions on boundaries in the address to denote hierarchy points. 3. "Longest match" - full addresses Currently hiearchical addressing is based on longest prefix match. Allows simple fallback in case primary route is not available. Full addresses need to be carried through the Internet (don't know how abbreviating addresses on local wire would work). These are absolute (non-relative) addresses. 4. Source Routes Current options are GRE and SDRP. 4a. Individual or anycast as individual elements Allow intermixing them freely. Fragmentation with anycast is problem. 4b. Loose vs. Strict Allow strict for anycast? But not across one wire. Strict source routing example: Debra Estrin routing fish Provider selection using GRE tunnels allows BGP between providers that are connected via tunnels. Paul: does not see need for strict source routing. John: NEARnet customers want choice of providers. Security concerns (Deering, Ran). 4c. What to do when next element on source route can't be satisfied: drop the packet and do nothing, drop the packet and send error message, route the packet, or route the packet and let them know. All of the above is taken from Yakov's internet draft. Peter: extensibility or variability of the address. This list does not seem to dictate that you need variable addresses? Yakov: yes it does, specifically #1 and #2. Yakov: 2 choices: choose today how many levels you need until 2015, or make it variable and just haggle about the boundaries. Peter: need to be able to extend the address to the right. 64-bit hierarchy to 96-bit hierarchy can work. Bellovin: need multiple addresses per host, aggregated. Fixed length addressing can work by reserving one byte or so for sysid. Yakov: shouldn't force on everyone the same level of complexity for address assignment. One provider may dictate complex address, another may simplify. Frank: how does this simplify routing table? What if multiple roots of hierarchy? Peter: explaining CIDR and hierarchical routing. Mixing public and private networks (there is a discussion of this in the CIDR doc). Can aggregate an entire large internet hierarchy into a routing entry within another Internet's routing table. Need to set up some rules ahead of time that public providers will follow. It is important to take sub-branches of a tree and glue them into parts of other trees. --- Steve Deering Last night, SIPP group proposed changing address to be 128 bits. Can embed the useful part of NSAPs (drop selector byte, 2-4 bytes of constant). One drawback of 16 byte address is what it does to the source route. SIPP does have a source route option - used for provider selection, possibly mobility. Source route from each leg gets swapped into the dest field, gets to be too long. It is desirable to make this shorter than 16 bytes. Options: 1. fixed addressed swapped into dest field 2. CLNP style (check both fields) 3. Ross's scheme: in main header, put source route and hops, with pointer in main header to currently active piece header discussed after the Thursday evening session broke up Fixed header 16 byte source addresss Sequence (optional) of source route elements - these could be shortened. Use 1-bit to indicate whether 8 or 16 bits. Or need to select 8, 16, 24 or 32. or 0, 8, 16, 24. 16 byte dest addresses Address starts of with some gorp, couple bits of length, or mask as byte count. Yakov source/loose bit with desired behavior (error reporting bit). Tony: 56(=32+16+8) bits, with 3 length bits in the middle of octet. Paul: should be 8 and 16 period. Length bit shouldn't be sitting in the middle of a field. Autoconfiguring router and end-system addresses. Need pointer to source routes, in fixed header at beginning. Source address should be adjacent to fixed header, to be near flow id, etc. Can we standardize on 24 or 32 bytes but mandate only 16 byte implementations? Cisco will implement routing on 56 byte addresses. Microsoft will implement header format for large addresses. Sun is concerned about testing if functionality is not needed initially. Dave K: transport identifier. If 16 octets will hold us for foreseeable future (long time), can we assume transport will not use network addresses as connection identifiers? This would get rid of one of the things that makes expanding the addresses difficult. For use with TCP, the profile is 16 octets. Jay: want to start using 8 byte addresses with variable length field. Remove restrictions. Small nets should be able to use short addresses, large nets need to be able to use large addresses. Bellovin: 16 byte number chosen randomly by initiator could be used as TCB. Will collide extremely infrequently. Peter: Jay is right. Extend off to the right. Use autoconfiguration ala Novell. Yakov: routing system today is capable of using arbitrary length addresses, using longest match algorithm. Mixture of private and public nets - one size fits all does not work. Ross: really want 8 and 16 to work, but 24 and 32 should work also. We should say 8 and 16 are required. Mark: are there bits in the fixed header at the beginning? No. Can use first 2 bits of the address fields themselves to indicate length. Solution (for round table feedback): 16 byte address with 2 bits in first byte indicating length. Need autoconfiguration and transition before Toronto. John: do autoconfig by e-mail and transition this afternoon. --- Roundtable: John: we have an approach to addressing, and loosely stated approach to routing. Get this down on powerbooks. Need approach to transition. Rob: this addressing thing is just fine. FIrst 8 bits should be length indicator, values would be 7 or 15. Put in code point for ISO. Steve Bellovin: generally happy with this. Mapping 8's to 16's may be necessary (fill with zeroes). Want bits on the right for multiple addresses per host, with autoconfiguration. Authentication has to be tied to host address that doesn't get modified along the way. Dino Farrinacci: where is the pointer, header alignment is good. Generally going in the right direction. Routing protocols will want to support all formats in a general way. Mark: ecstatic. Propose single IPng group, chaired by Deering and Rekhter. Steve Deering: could be happy with this. Providers should apply discipline in their bit allocation. This is not SIPP, we won't re-lable this SIPP. SIPP is 128 fixed address. Steve may not want to write this protocol spec. Erik Nordmark: looks reasonable. Need low enough upper bound on length of addresses for host/server performance. 16 bytes is reasonable. Routers should be able to handle longer ones. For running TCP and UDP over this, 16 seems to be the right things. Bob Gilligan: like feature of having option to use 8 byte addresses, chance of small packets and reasonable performance. Will take fair amount of work (eg. SIPP took a long time). How does this affect API. Frank: Cautiously optimistic that we can do the right things with this. Fill in fields on white boards. Does multicast work? Provider selection, network layer services - how do they work? This is the best fit so far, needs to think about it. Ran: This has been very productive, would like to see rest of header get fleshed out before signing off. Need IANA as top level authority. Can't get NSAP in Navy currently, but can get them from IANA. Navy can't decide how to structure their address space. Like granularity fixed at 8 bytes. Want to see separate group exploring the notion of how to deal with transport ids in variable address world. Lixia: Support Ron A.'s suggestion of setting up a separate working group to look at EID issue, though we may have different visions on where it may go. Would like to see a single IPng group finalizing protocol. Do not think variable length address buys us anything if it only grows to the right, in which case the smaller your address is, the larger amount of address space you have consumed. Discussion: how to add address space in the middle of hierarchy. Sue: this is a positive step. There are details to work out, eg. upper bound of address. Echo Lixia, separate group look at EID to make decision once and for all. Eric F.: Overjoyed that one size fits all mentality is being eliminated. Glad to see flexibility. Doesn't understand the format. How do pointers work? Do we really have a compromise? Have we just pummelled certain members of the group into silence? How are SIPP/TUBA/CATNIP groups going to be informed? Don't need another working group, those groups are obsolete. We can't decree, has to be community-wide thing, don't know how this is going to be done. Discussion: What changes to criteria doc need to be made? Scott and Allison aren't going to convey this consensus to the world. Technical feedback is still needed. General sense that the rest of the header looks like SIPP, not starting from ground zero. Jay: great, had been waiting for variable length SIPP addresses for a year. Would be non-trivial to dissolve groups. Peter: several things still need to be worked on. Real challenge is in the addressing plan. Steve D. and Peter are the last people that believe there will be a geographic hierarchy out there,how to make all of these hierarchies work together. Paul's documents. Paradigm of extension needs to be thought of, if 10 hosts encode in a byte, what do to for bigger networks. Very important to extend off to the right. Peter's house now has a routing architecture. Very happy about what has happened. Yakov: no comments, have spoken enough in last 2 days. Paul: We've explored alternative possibilities. EIDs, alternative EIDs, don't know how to work with them yet. We are going to use what we are familiar and comfortable yet. Want to see a small number of people in this room work out a straw header this afternoon before leaving. Side bet: these numbers will be larger than 20 bytes from the beginning. Whatever the largest system that works within one year of deployment will be the largest system we ever have. Greg: Killer things have been sort of fixed. Share Jay's concern about merging into single IPng group. Still a lot of points of disagreement about what fields mean, what bits are in the header. Get those things out. Talk about 2 packet formats. Lixia's take on Ran's suggestion is opposite to greg's. Greg wants to see transport identifier working group. Tony: pleasantly surprised, had low expectations. very happy with what's been proposed here. Usual bit-twiddling implementation haggling he likes. Tony and Rob Ullman will volunteer to chair the IPng Working Group if Steve and Yakov don't accept. Discussion: Allison: Continue the header drafting team started last night. Dino, Tony, Yakov, Erik N., Steve D., Lixia, Paul, Dave K. Dave K: Don't care where the bits are as long as they are mostly the right bits, SIPP header has mostly the right bits. Trust Tony to twiddle bits. Biggest short term challenge is politics and PR. Who owns these proposals and drives the result? Who gets to say no. Discussion: Who gets to resolve disputes in IETF if there are competing options. COnsensus is benevolent dictatorship taking people to dinner. Dave hopes to be pleasantly surprised. Memoirs should say we had fancy dinner and were pummelled. Ross: this compromise is technically superior over previous proposals. One big concern: while addressing is critically important, the transition issue is just as important. Fewer people have experience with transitions, could shoot yourself pretty badly. Don't have consensus on that yet. Discussion: compromise was better than 14.5 byte address. end of round table ----- Dave P's notes from the retreat IPng Retreat These notes reflect my best guess at what was discussed during the IPng retreat, 19 May 1994. 1. Structure & ground rules Directorate and guests distinguished by their roles (directorate conducts discussion, guests add when called upon to do so). We began by generating a list of general and proposal-specific concerns among the directorate and guests: % (Ross Callon). IPAE transition plan mapping, translation table, SIP Addressing. % (Dino Faranucci). Addressing size and EIDs; use of existing routing protocols and longest-prefix match vs. PIP; transition as it impacts routing. TUBA good if remains CLNP and no impact to existing definition and infrastructure. CATNIP not sufficiently documented. SIPP must simplify or eliminate IPAE (fatal problem) and simplify routing headers. % (Tony Li) problems with addressing and routing header in SIPP, agrees with Dino. % (Greg Minshall) Autoconfiguration issues with SIPP, addressing, max segment lifetime. Alignment of transport header in TUBA, TUBA generates CLNP ERs vs. ICMP messages. General: flows and maximum payload size? No such thing as CATNIP (context: wants to dismiss it to reduce alternatives to two). % (Paul Francis) Dismisses CATNIP from political perspective. No fatal flaws in any proposals. Specific concerns: TUBA benefit is CLNP stability, acceptance, but weak in terms of routing capabilities (provider selection). IPAE transition is problematic. % (Yakov Rekhter).Semantics overload (preoccupation with number and alignment of bits in headers may lead to overspecification of individual bits. Concerned about (generally) transition (uncoordinated and piecemeal deployment), addressing, routing. Need to have as a goal a common ground for migration of other protocols (IPX). % (Peter Ford). Semantic overload problem, transition should be separated from proposals since they can be implemented with any of the IPng proposals. IPAE is broken within the context of autonomous system deployment, not generally broken. Extensibility of addressing. The selection process is tragically flawed; close working groups and have all WGs participate towards a single solution. % (John Curran). Need a single design team working on developing a consensus. EIDs and transport independence over the network layer (TUNE). CATNIP excluded because it begs off the technical criteria. IPAE is fatally flawed. Operational impacts in SIPP (routing paradigm and IPAE) are not easily overcome and should not be dismised. % (Jay Allard). Autoconfiguration is important and should have variable payload support (configuration is more than addressing (SIPP is broken, CLNP falls short). Transition issues. Doubt SIPP64 addressing scheme is sufficient, and extended addresses don't fit within all aspects of proposal (DNS, DHCP, EIDs). NSAPAs are extensible (in SIPP header). APIs should be added to requirements document. Autoregistration of addresses in the % (Eric Fleischmann). What additional functionality is brought with each proposal. Too much additional risk over IPv4. Provider based addressing is flawed and a bad thing. NSAPAs as defined are too broad and chaotic to be practical. IPAE is broken. SIPP cannot meet Boeing's addressing needs (fatal) % (Sue Thompson). Global EID point. % (Jim Bound). Doesn't like variable length addressing; need good autoconfiguration and EIDs % (Lixia Chang). CATNIP not considered. Concern TUBA and cost of dual stack transition. General: authentication and accounting. % (Frank Kastenholtz). Architectural and future perspective of all proposals; network service models and CATNIP incomplete. % (Ran Atkinson). CATNIP not sufficiently defined. Transition is separable; exploring SIPP dual stack is useful. Need authentication mechanism that does not rely on confidentiality primitives from day one. Need multicast support that works and hooks for resource reservation. Need solution that works with low bandwidth high delay networks. % (Bob Gilligan). TUBA transition is difficult and too expensive Q double everything, doesn't allow for eventual introduction of a TUBA only host. TUBA packet is too big. % (Steve Deering). CATNIP reassembly at intermediate points, transition and interoperation (semantic preservation), scalability of routing in a CATNIP environment. TUBA/CLNP Q multicast design is complex and redundant. Routing processing issues (general). % (Dave Katz). Overall issue with routing, addressing, EIDs. How to motivate folks away from IPv4 addressing. General issue is whether there is a user motivation to accept any of this. % (Mark Knopper). IPAE is fatally flawed from an operations perspective. TUBA has operational advantage. Addresses must work. % (Dave Piscitello). Addressing size and issues in future "assign, use, and discard scenarios"; IPng aversion syndrome with regard to renumbering (should solve the problem by making it easy to do). Authentication and accounting more important than flows; obsession with the packet rather than the system. % (Steve Bellovin). Security issues are separable from choice of protocol, must be resolved at higher (meta-) level. IPAE is a non- starter; dual stack initially and translators later (interesting). What the hell is an EID? Which alternatives can work in large scale networks. Is TUBA a non-starter, since convergence with OSI seems to be a non-goal. (anecdote from ARPAnet "long address leader"transition circa 1980, when the size of address space in NCPs/IMPs Q maintaining a cache/hash "near the host".) % (Rob Ullman). TUBA and SIPP change the definition of TCP & UDP checksums. IPAE is fatal, SIPP would be better off without it. 64 bits may work, but we ought to consider NSAPs if addresses are to be of variable length. Security proposals are orthogonal to network layer; interaction between SIPP security proposals and addressing is a major weakness. New addressing, border routing cause retraining problem. Payload sizes and identifiers are too small for SIPP and TUBA. SIPP will look like a new protocol irrespective of how it's sold; it's not an easy mod to add. % (Erik Nordmark). Dual stack won't work, requires too much synchronization; need a piecemeal transition that works. What do we do about route scaling during transition? EIDs and locators opens new security issues? Having concluded the quick critique, the IPng directorate agreed that they would separate out transition plan evaluation from the evaluation of individual proposals. Will focus on transition topic on Friday, 20 May 1994. 2. Address size for IPng. Eric Fleishman explained why he believed that SIPP's 64-bit addresses are insufficient for even Boeing's private network (currently have 28 Class B and 150 Class C networks). This is an example of the sort of aggregation problems end users discover when they receive a piddling amount of bits out of a total of 64 bits for locators (64 - n - m - p) following the provider assigned. Yakov indicated that Eric's scenario illustrates that hierarchical address assignment can seriously prune the available space. Tony Li suggests that the granularity of hierarchies is problematic (citing that users won't budge from octet boundaries for hierarchies). Dave P. suggested that the directorate is making some fundamental assumptions about address consumption, use, and permanence that he's not sure are appropriate. 3. Address encodings & general network header issues. Minshall and Bound insist that network layer protocols that, upon composition (including variable length fields), leave the transport header in other than a predefined location are bad, and that we should insist that NL protocols "pad" to align the transport header to 32-bit boundaries. Must ensure that every NL protocol accommodate padding along so that the transport header begins on a 32-bit boundary. Header length must be zero mod 32 (affects RFC 1561). 4. System Identifiers Essential for autoconfiguration; these are identifiers that a host is provided with "at birth" (birth here meaning prior to network attachment/advertisement). 5. Endpoint Identifiers Do we need them? This is a very active discussion topic, but the directorate must have an answer to this. What are they? Chiappa and Salter (according to Ullman) it is the endpoint of a transport process on a machine. Has nothing to do with vendor stamped number (this is what Dave P. describes as a system id Q in OSI routing, the SNPA embedded in an NSAPA). John Curran suggests that there is no independent component from the IP header (address, PROTO, etc.) that distinguishes a transport entity. In OSI addressing, TSAPAs serve this purpose (but OSI blew it and left transport addresses as locally significant suffices of NSAPAs.) One way to describe an NSAPA is having 3 elements: the locator, which is the entire NSAPA less the last 7 octets of the NSAPA; the 6- octet system identifier is used for autoconfiguration, and the {system identifier, N-sel} pair can be used as an EID. Here the system identifier must be globally unique. Deering suggests that one can have a separate EID from the NL address, in which case the NL address is not overloaded with EID but DNS mapping is painful. A third alternative is that the whole address Q locator and EID Q are inseparable and one (IPv4 address). This is the problematic scenario Curran wants to avoid. TUBA, SIPP, and IPv4 are all using the third alternative right now (computation of tcp pseudoheader) Structure? For security purposes, it should have some organizational structure. Steve Deering suggests that EIDs could be composed of a globally unique vendor stamp plus some other bits. Are they globally unique? No one answered this directly but the consensus seemed to be that if they are needed, they are probably globally administered. What are they for? Ross suggests that they may be used to "stamp" a device (at birth) with a globally unique identifier, and by stamping the device with a (again globally unique) "where" (a locator part) independently from the identifier, things like filtering, autoconfiguration, and mobility, etc. I think this is only partly correct; an EID is not necessary for autoconfiguration; this is the purpose of a system identifier (i.e., in RFC 1523). Paul Francis suggests that it is necessary for server-less autoconfiguration; in this case, an EID is a number that is given to a machine at birth (like ethernet addresses). Once you have this, it can be used as a location-independent "cookie" to identify a machine. For DNS or security, it's not necessary to have an EID. Yakov suggests that in IPv4, a semantic overload exists in the 32-bit address, as it is used for hierarchical routing and transport connection endpoint identification. EIDs introduced as part of the network address structure perpetuate this in IPng. Yakov draws the distinction that you use flat routing (i.e., beyond the location) vs. network numbers (which provide hierarchical routing) My interpretation is that for mobility, I'd use the network address as a means of determining the current location ("where") of a host, and within the context of that location, I'd identify the host ("who") through the EID (as opposed to an ethernet address, which is (a) technology specific, and (b) a semantic overload of a physical address) John Curran suggests that the re-use of NL addresses as transport connection identifiers are bad since network level identifiers change, and transport level identifiers are "mapped" onto. Defining transport level identifiers independent from network addresses improve ability to deploy mobile hosts. Dino suggests that since network layer (and routing) requires potentially variable length addressing for scaling, while hosts want to parse fixed length identifiers, separating locator from identfier seems to be a win-win situation. Greg Minshall suggests that these uses may be mutually exclusive (see sysids vs. EIDs, above). IPng retreat analysis of SIPP Addressing (Curran). SIPP addressing, as defined, are locators plus system identifiers, and this will not scale, nor will they be useful for mobility except by using extended routing headers (see above). Paul Francis attempted to dismiss this notion by reviewing the "brand new" SIPP address formats, which include both a 64-bit locator and a 64-bit local-use address, described and posted a week ago. Rob Ullman blew away the smoke and mirrors, suggesting that the reason this was introduced was simply to disguise the fact that 64-bit address was too small, and he suggested that SIPP admit the addresses are too small, redefine the SIPP header, and unite the locator and identifier into a single 128-bit address. (Small round of applause). My understanding of Paul's reply was that the engineering model within which the SIPP is architected desires to preserve fast-forwarding and processing, and extensions to the basic address could be incorporated into the (loose source) routing header. Yakov and Dino jumped on this, indicating that this overloading of the routing header is just as problematic (forwarding time processing intensive). Dave Katz pointed out that the source-routed addresses are rather local context sensitive, so it's rather difficult to determine how a firewall and filtering, etc., can be applied. Bellovin asked about the relationship between the 64-bit and source addressed strings and what is returned to gethostbyname in a DNS "A" record:-) No reply. I asked the question a second time, Paul indicated that the {locator, system identifier} 64-bit pair would be returned. John pressed whether the problem with overloading the source routing header in this fashion wouldn't be absolved by having variable length addressing in the fixed part of the base header. Peter Ford pointed out that his experience with customers and end users is that they are willing to eat larger addresses, etc. for ease of configuration, simplified registration, etc. Ullman supported this, saying that whatever you design, you must be able to describe to the end user world. Jay Allard suggested that (a) configuration, DNS autoregistration, and larger (more flexible) locator parts to addresses are necessary, (b) everyone agrees that it is necessary, and (c) everyone agrees that the proposed 64-bit base plus extension is broken, SIPP should fix it. Peter suggested we want to talk seriously about using SDRP, variable length addresses and hierarchical routing as an alternative to loose source routing. Evaluation of TUBA/CLNP addressing Dave P and Dave Katz led a discussion on NSAPAs, their composition, how they are assigned and deployed, both on the Internet and generally within OSI, debunking myths along the way. The general notion these and the rest of the TUBA folks managed to express is that the CLNP technology is not fundamentally different from IPv4 in addressing (except for the ability to convey a system identifier suitable for autoconfiguration), hierarchical addressing and provider based addressing as per CIDR, and routing technology used in IPv4 is either already present or can be ported (i.e., SDRP and other source routing/reservation routing methodologies). Transition (Clever comment of the p.m.: when I suggested that SIPP changed rather frequently, Erik Nordmark pointed out that, after all, SIPP is a real-time protocol. Number two: Dave Katz "Cisco has already sold products to all the smart customers...."). ------ these are some notes taken by Dino of the results of the packet format discussions on friday afternoon. ------------------------------------------------------------------------ With new address format and to allow for the source route to be implicit in the main header, we had to do some rearranging of the SIPP header. Field requirements: Begin Offset/End Offset: To encode list of intermediate and destination addresses. Flow Id: Relocated to be adjacent to Source address. Payload Type and Hop Limit: Unchanged from SIPP with respect to length. Payload Length: Increased to fit where Flow ID use to be. Intermediate Address: If pointed to by Begin Offset, is the address a router uses to forward on. Address Formats: high-order 3 bits in address determine length of address. Lengths are in 8, 16, 24 byte lengths. We discussed at length if the Flow ID should be present in every packet. Since the semantics of Flow ID are unknown, we were trying to trade-off the extra 8 bytes in the header (to keep addresses 8-byte aligned) with performance considerations when Flows will be used in every day life. Header Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End Offset | Begin Offset | Payload Type | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R L L| | +-----+ -+ | | +- Source Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R L L| | +-----+ -+ | | +- Intermediate Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o o o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R L L| | +-----+ -+ | | +- Destination Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version (4-bits): 6 Flags (4-bits): TBD Payload Length (24 bits): Length of packet not including the header. End Offset (8 bits): The byte offset of the byte proceeding the Destination Address. Begin Offset (8 bits): The byte offset of the next address to process in the Destination Address sequence. If Begin Offset is equal to End Offset, there are no more addresses and packet should be discarded if it is not the received system's address. Payload Type (8 bits): SIPP Payload Type values. Hop Limit (8 bits): Same as SIPP. Reserved: Must be sent as zeroes and ignored on receipt. Flow ID: Same semantics as SIPP. Source Address: The address of the system which originiated the packet. Intermediate Address: One or more intermediate systems or clusters that can be traversed to deliver the packet to the Destination. This is used as a loose source route and is a replacement of the Routing Header. Destination Address: The address of the system to receive the packet. Options: Same as SIPP with one exception. The Routing Header is no longer present. ------- Note: recently an internet draft has been published by some of the people involved in the BigTen packet format discussions that offers some suggestions for further refinement.