IPNG (ipngwg)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s): 

Bob Hinden <hinden@ipsilon.com>
Steve Deering <deering@cisco.com>

Internet Area Director(s): 

Frank Kastenholz <kasten@ftp.com>
Jeffrey Burgan <jburgan@baynetworks.com>

Mailing Lists: 

General Discussion:ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: subscribe ipng
Archive: ftp://parcftp.xerox.com/pub/ipng

Description of Working Group: 

Editor: Bob Hinden (hinden@eng.sun.com) 

The next generation of the Internet Protocol (IPv6) is intended to support Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service. This working group will produce specifications for the core functionality of that service. The working group shall carry out the recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in ``The Recommendation for the IP Next Generation Protocol,'' Internet-Draft, (draft-ipng-recommendation-00.txt), September 1994. 

The working group shall use the following documents as the basis of its work:

·   Simple Internet Protocol Plus (SIPP) Specification (128 bit version) 
·   SIPP Addressing Architecture 
·   An Architecture for IPv6 Unicast Address Allocation 
·   Simple SIPP Transition (SST) Overview 
·   SIPP Program Interfaces for BSD Systems 
·   SIPP Security Architecture 
·   SIPP Authentication Header 
·   SDRP Routing Header for SIPP-16 
·   IP Next Generation Overview 
·   ICMP and IGMP extensions for SIPP 
·   FTP Operation Over Big Address Records (FOOBAR) 
·   DNS Extensions to support SIPP

Enhancements to be considered:

Large Packets: Consider extensions for support of datagrams which are larger than 64K. 
Source Routing: The working group shall consider enhanced source routing capabilities for IPng. 
Tunneling: Complete specification of IPng in IPng tunneling.

Address format and assignment plan: The working group shall review the details of address structure as specified in [SIPP-16] and shall repair any deficiencies with respect to current or near-term addressing requirements, assuming a fixed, 16-byte size. The specification shall provide a mechanism for supporting multiple additional formats, for possible enhancement to incorporate other popular addressing schemes. 

Routing Structure: In completing the addressing details, the working group shall ensure that routing according to current, CIDR-like schemes can be supported comfortably. 

Autoconfiguration: Coordinate with the IPng Address Autoconfiguration Working Group. 

Transition: The working group shall coordinate with the related transition and conversion efforts (ngtrans, tacit, nosi, etc.) to ensure that the base specification provides the facilities required for the transition from IPv4. 

Security: A set of base documents for IPng security shall be completed. This shall include algorithms for authentication and privacy carried as IPng extension headers and include an initial selection of required encryption and key management algorithms and a facility to support other optional algorithms. The working group should also examine IPng firewall issues and if necessary develop specific firewall frameworks. 

Minimum MTU: Consider a larger minimum MTU. 

Header Compression: Consider ways to abbreviate the IPng header in the contexts of native IPng, multiple IPng packets in a flow, and encapsulated IPng. 

TCP/UDP: The IPng Working Group will specify the procedures for hosts to compute and verify TCP/UDP pseudo-headers. Any other changes to TCP beyond making TCP work with IPng are out of scope of the working group and should be dealt with by a TCPng Working Group. 

The IPng Working Group will coordinate with other groups, including Mobile IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR, Security, Applications, Network Management, and IP over ATM, etc.

Goals and Milestones:

Done 



Submit preliminary IPng core specifications, with required enhancements, as Internet-Drafts.

Done 



Submit revised core IPng specifications as Internet-Drafts.

Done 



Submit core IPng specifications to IESG for consideration as Proposed Standards.

Feb 95 



Submit extended IPng specifications as Internet-Drafts.

Mar 95 



Submit extended IPng specifications to IESG for consideration as Proposed Standards.

Jul 95 



Submit revised specifications to IESG based on implementation experience for consideration as Draft Standards.

Oct 95 



Submit revised IPng specifications as Internet-Drafts.

Dec 95 



Submit final IPng specifications to IESG for consideration as Standards.

Internet-Drafts: 

· Basic Socket Interface Extensions for IPv6 

· Generic Packet Tunneling in IPv6 Specification 

· Link Local Addressing and Name Resolution in IPv6 

· IPv6 Router Alert Option 

· IPv6 Multicast Address Assignments 

· IPv6 Routing Table Size Issues 

· IP Version 6 over PPP 

· Management Information Base for IP Version 6: Textual Conventions and General Group 

· Management Information Base for IP Version 6: ICMPv6 Group 

· Management Information Base for IP Version 6: UDP and TCP Groups 

· GSE - An Alternate Addressing Architecture for IPv6 

· Transmission of IPv6 Packets over FDDI Networks 

· Transmission of IPv6 Packets over Ethernet Networks 

· Synthesis of Routing Goop and AAAA Records in IPv6 

· IP Version 6 Addressing Architecture 

· IPng Analysis of the GSE Proposal 

· Router Renumbering for IPv6

Request For Comments:

RFC 

Status 

Title

RFC1884 

PS 

IP Version 6 Addressing Architecture

RFC1883 

PS 

Internet Protocol, Version 6 (IPv6) Specification

RFC1885 

PS 

Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)

RFC1887 

An Architecture for IPv6 Unicast Address Allocation

RFC1886 

PS 

DNS Extensions to support IP version 6

RFC1897 

IPv6 Testing Address Allocation

RFC1981 

PS 

Path MTU Discovery for IP version 6

RFC1970 

PS 

Neighbor Discovery for IP Version 6 (IPv6)

RFC1888 

OSI NSAPs and IPv6

RFC1972 

PS 

A Method for the Transmission of IPv6 Packets over Ethernet Networks

RFC2019 

PS 

Transmission of IPv6 Packets Over FDDI

RFC2023 

PS 

IP Version 6 over PPP

RFC2073 

PS 

An IPv6 Provider-Based Unicast Address Format

Current Meeting Report

Interim Minutes of the IPng (IPNG) Working Group 

February 27 & 28, 1997 / Palo Alto, CA USAReported by: Bob Hinden 

Meeting hosted by Allyn Romanow / Sun Microsystems, Inc. Many thanks to Allyn and Sun for this service to the IETF. 

I. Agenda 

Thursday 

Introduction 

Review Agenda 

8+8 Overview 

Detailed Review 

Uniqueness of ESD's 

DNS forward lookups 

DNS reverse lookups 

DNS Structure 

TCP/UDP Connection Identification 

Effects on Applications 

Rewriting of RG (inbound, outbound) 

Lunch 

Continuation of Detailed Review 

Map RG into current Internet 

Rehoming Site 

Multihoming Site 

Rehoming Multihomed Site 

Rehoming Small Provider 

Multihoming Small Provider 

Rehoming Multihomed Small Provider 

Summary of Discussions 

Friday 

Review Remaining Agenda 

Review impact on existing specifications 

Base IPv6 Specification 

Addressing Architecture 

Provider Based Addressing Documents 

Neighbor Discovery 

Address Autoconfiguration 

IPoverFoo 

ICMP 

Lunch 

New documents which need to be written 

GSE Specification 

ESD Guidelines 

RG Allocation 

Impact on Implementations 

Summary and Conclusions

II. Review of Agenda 

There was a discussion regarding the purpose and outcome of the meeting. Possible outcomes: 

· Working group will not adopt GSE proposal. 

· Working group will adopt proposal. 

· Working group leaning toward adoption, but there important missing pieces that must be specified before the working group can make final the decision 

What problem is this solving? Suggestion was made to generate list of pros and cons.

III. Problems being Solved / Mike O'Dell 

A. Goals and Non-Goals 

Goals: 

Thinks biggest problem in internet is complexity of routing computation in the backbones (where there are no default routes). Specifically, the cost of BGP computations increases as internet grows and policy issues become more complex. Thinks computation growth is exponential. Issue is that from a routing perspective the backbone is relatively flat. 

Why is this better than current provider based design? Current provider based topology schemes rely on renumbering sites to improve route computation. He thinks the aggregation model for provider based addressing has potential for catastrophic collapse. What could happen is that a few very large sites will refuse to renumber (i.e., lawyers go to court), and that will effectively stop everyone from renumbering. CIDR has worked well, but will not continue into the future. 

GSE deals with this problem by keeping changes resulting from renumbering the internet local to edge of site, and keeps changes from propagating into the site. Internal routing infrastructure is isolated from external changes. 

Proposal allows backbone routing topology to change independently of sites without having to get the sites involved. Advantage is that this allows 

backbone renumbering to happen independently from site renumbering. 

Allows multihoming without increasing size of backbone routing. This is important because more and more sites are becoming multihomed. Also helps second tier providers to change their first tier providers without forcing their customers to renumber (and potentially losing their customers). This is a very important benefit. Comment by Masataka Ohta: Doesn't think this completely solves multihoming, but it is a good first step. 

Non Goals: 

Does not solve mobility problem. Does not keep TCP connections alive during renumbering. It would be nice to have TCP connections survive loss of one connection when multihomed.

IV. Uniqueness of ESD's 

6-Byte IEEE Mac's are proper subset of 8-byte IEEE-1394 (firewire) addresses. 

Are they unique enough? 

Dimitry Haskin said he doesn't like using MAC addresses for ESD's. He would like something that has same properties of current IP address. Discussion about how most sites will use MAC, while still allowing sites to use something else if desired. 

Jim Bound thinks it is unique enough. ESD should be 8-bytes long. A discussion about this followed. 

Thomas Narten: What are the consequences if there is a collision? Easy to detect on a link, but hard to detect globally. 

Steve Deering suggested that it is a relatively low probability event. We could later build in additional mechanism to help deal with this. 

Are IEEE1394 addresses compatible with SMDS addresses? Not an issue, SMDS addresses are E.164. 

Erik Nordmark: Think they are unique enough. 

Hinden: Thinks MAC address will be unique enough. He mentioned that MAC only addressing has been used successfully in large bridged networks and in large IPX networks. In addition, IPX networks are mostly PC, which is the area where there has been the most concern about duplicate MAC address. 

Bound: Do we have a consensus on uniqueness? 

Questions about systems (such as Sun's) which only have one MAC per Node? Long discussion. 

Group concluded that IEEE Mac addresses are unique enough to serve as globally unique ESD's. 

V. Does ESD need to have structuring? 

Masataka Ohta: Thought they should have structure for security. Discussion about this point, concluding that structure was not necessary for the purpose. 

Jim Bound: This all requires changes to DNS. Everyone agreed. He does not think there is a need for structure in an ESD. Assumption that to do reverse mapping is more difficult if there is not some structure in ESD. Discussion of this point followed. 

Discussion evolved into what are requirements for reverse mappings of ESD's. Alternative suggestion was made for ICMP "Who Are You" with ICMP "I Am XXX" message returning DNS name to perform this reverse mapping function. 

We will need manual defined ESD space, but this should be the exception. Most nodes will not need to use it.

VI. Discussion about Adding Routing Goop Records to the DNS 

Proposing to add "site names" to DNS. Would correspond to routing group for site. Could reverse lookup RG to "site name". "Site name" is not the same as DNS suffix. 

Important to only do connection identification using only ESD, not RG+ESD. This will allow future development of secure RG redirect later to improve transport behavior when RG changes. 

The assumption is that site renumbering is relatively infrequent, not a frequent "real time" event. 

Discussion followed about use of RG as identifier for site and effects on firewalls. 

There will not be inverse lookups of IPv6 addresses! It will be replaced by ICMP "Who Are You" message. 

Matt Crawford raised issue about rate limiting "Who Are You" messages. He is concerned if senders don't cache answers. This could create a heavy load of "Who Are You" message. An alternative is to have the DNS servers send the "Who Are You" message when they receive a reverse mapping request. This seems to be a good idea. 

Rough consensus of the group is that ESD's do not need to have structure. 

Dimitry Haskin pointed out that for links that do not have MAC such as PPP serial links, we could no longer auto-configure these links. ESD's for these links will be manually assigned. This is about the same as IPv4 operation today, but not as good as what the current IPv6 over PPP specification provides. Is this an acceptable limitation? 

Discussion about use of random numbers as ESD tokens. Are they unique enough, etc. Not much agreement on using random numbers as ESD tokens.

VII. Mike O'Dell Presentation on Multihoming 

Provider Provider 

1 2 

+----+ +----+ 

| | | | 

| | | | 

|PBR | |PBR | 

+--x-+ +-x--+ 

| | 

RG1| | RG2 

| | 

+--x-----x--+ 

| SBR SBR | 

| | 

| Site | 

+-----------+ 

If RG1 link fails, then Provider PBR tunnels traffic that would have been sent to the site via RG1 and sends it to the Provider 2 via RG2. Requires that both PBR in site 1 & 2, and SBR's understand that tunnel has been created. 

If TCP saves RG when SYN packet is received for connection, and never switches to RG received in subsequent packets, it can protect against its connections being hijacked. 

A long discussion followed, with even more complicated pictures and scenarios. 

Hinden asked question of how this was different/better from what can be done with current IPv6 specifications. Not clear what the win is here for multihoming. 

Erik Nordmark made observation that if node remembers all of the RG's returned from the original DNS lookup, then it would be OK for it to switch to one of the returned RG's if packet started arriving from a different one. 

Rebecca Nitzen talked about how in this scheme it will be very easy to load share multihomed site. Traffic in both directions will follow the same route. The only thing necessary to do is divide the primary default between the ISP connections. Might also be possible to return DNS replies for the site to divide the load by replying with the appropriate RG based on where the requester is.

VIII. TCP/UDP Connection Identification 

Pseudo header checksum always use ESD. 

Do we require all unicast to work the same way? Yes. OK for provider addresses which are autoconfigured. Important to require all addressing plans to have same characteristic. 

How about multicast addresses? Include an ESD? 

Discussion about what to do when node starts receiving packets with new routing goop. When node does not have any other information, node should drop packet. If node thinks the new routing goop is valid (perhaps by having received it in original DNS lookup) then it can reply and start sending to new Routing Goop Need to look at what happens if routing goop is corrupted? This needs analysis to access the impact. 

Long discussion about if some of the RG could be included in the checksum. Allison proposed having the host include its RG in checksum. Not clear how source node would get RG. Makes rewriting RG on in bound traffic impossible (?). This could be viewed as a hybrid proposal. 

Mike O'Dell suggested that TCP should not bind to a particular RG for remote side until three way handshake is completed. 

General comment made that it is important that this proposal not change TCP protocol. No TCPng!!!!!! 

Long discussion about what happens if RG is corrupted. Worst case is when first SYN packet is corrupted because connection will never be established. 

Erik Nordmark asked would implementing this architecture make it harder to make changes to TCP later in the future? What is the effect of hiding RG from the host? 

Matt Crawford proposed that we continue to rewrite RG, do not include RG in pseudo checksum, non-established TCP treat packets with different RG as different connections, for any UDP or TCP in established state pass all packets to application, connected socket for any transport do not update outgoing RG address. 

Long discussion about connection identification, checksums, what happens when RG changes, etc. 

Jim Bound stated that renumbering while important, it is not on the top of the list of what his customers wanted. 

Friday 

Introduction to meeting. Today will continue detailed review of proposal. Start with DNS issues. Continue to work through the list: 

Uniqueness of ESD's 

DNS forward lookups 

DNS reverse lookups 

DNS structure (effect on caching, performance) 

TCP/UDP Connection Identification 

Effects on Applications 

Rewriting of RG (inbound, outbound) 

Effect on V6 mobility, multicast, and anycast

I. DNS Forward lookups 

What if site is multihomed, does requester get multiple DNS entries? 

Two-faced DNS 

Solution: Remote DNS are sort of part of local universe, so they need to know site RG and provide appropriate answer. 

Jim Bound: Thinks the split between RG records and AAA will work. Suggested list of topics to discuss on DNS: 

A. Boot strapping DNS delegation records 

B. How do replies get fabricated 

C. What new record Types 

D. Two-faced DNS 

E. Dynamic Update to RG (for renumbering)

A. Boot strapping DNS delegation records 

Need to have hard coded address of DNS servers. For example, to get to foo.sun.com, .com server needs to have address of ns.sun.com. This is the way IPv4 works today. Discussion focused on making DNS servers have addresses that are not renumbered. This should work as long as there are not too many DNS servers. Need to update DNS servers when RG changes. Likewise this is essentially the same as IPv4 and a general IPv6 issue not specific to this proposal. 

When site renumbers, it must change its DNS servers. When an ISP renumbers it must make it transparent to sites. O'Dell suggested that if DNS servers get RG info from routers this could be made easier. 

Problem could be made less severe if the top-level name servers had addresses that were not renumbered. We could support some amount of non-renumbered addresses for important servers. 

Important to identify where in DNS there are hardwired addresses. 

Thomas Narten: This is a generic point about renumbering, not specific to this proposal.

B. How do replies get fabricated 

Matt Thomas suggested that AAA record be split into Subnet + ESD record (AA). Matt Crawford agreed this would be a good idea. We do need a site record for RG? General conclusion that splitting the DNS records was a good idea even if proposal not adopted in whole. 

C. What new record TypesRG RecordAAA (Deering suggested calling it "aAA")D. Two-faced DNSServer has to have information to know what kind of reply to send. If RG of source address from request is same as RG which was to be in the reply, it should substitute site local RG. 

Matt Crawford described a problem where DNS queries are forwarded between servers, RG will be lost as request goes between sites and backbone and this will not be work. 

General conclusion is that these topics need an owner to describe how all of this works.

E. Dynamic Update to RG (for renumbering) 

Decided this was a future need and is not required now for this proposal.

II. Effects on Applications 

Prohibition of Storing non-refreshed non-ESD addresses. Not specific to this proposal. General renumbering (and transition to IPv6) issue. 

· Use only ESD for peer identification (not address). 

· Avoid carrying addresses in payload. 

· Flow identification. Probably need to only use ESD instead of whole address. 

· Effect on reassembly. 

· All packet identification needs to use ESD's. 

· Effect on routing header? If RH is to be replied then BR would have to fix up RG inside of RH. This happens on both first exit BR and final BR. Not clear if it is important to make source routes RH reversible. Border router, which may not be one of the SR hops, will have to know to look inside of RH to rewrite appropriate RG's. 

· Might be better to embed DNS names in packets because they are global and can be looked up. 

· Comment that overall this adds complexity for programmers. They will need to have good understand of RG, subnet, ESD's, addresses, and how they interact. Prior to this proposal, they only needed to understand addresses. 

· Effects on tunnels. If tunnel crosses site boundary, end points must perform BR functions. Which router does rewriting? Long discussion on how this works. End point of tunnel needs to be able to rewrite destination RG w/site prefix. Host-Host secure IPSEC tunnels require hosts to be able to recognize that the RG (actually it's own) is one of it's interface and accept the packet. 

· Anytime you tunnel, it in effect requires all tunnel end points to be border routers. They need to be able to rewrite RG on exit and entry. 

· Renumbering breaks all configured tunnels. 

· Addresses in MIB's and Address in SNMP Traps. Makes it harder for agents. 

· ICMP error messages. Returned packet has packet with error. Need to look only at ESD to match error reply.

III. Steve Deering's fortune cookies from lunch 

"A thrilling time is in your immediate future" 

"Avert misunderstanding by calm, poise, and balance" 

"He who hurries cannot walk with dignity" 

"If your desires are not extravagant they will be granted" 

"Simplicity and clarity should be your theme in dress" 

"Strong and bitter words indicate a weak cause" 

"The best prophet of the future is the past" 

"The laws sometimes sleep, but never die" 

"Time is precious, but truth is more precious than time" 

"What's vice today may be virtue tomorrow" 

"Wise men learn more from fools, than fools from the wise" 

"You have a quiet and unobtrusive nature" 

"You will be recognized and honored as a community leader"

IV. TCP Connection Identification / Matt Crawford & Allison Mankin 

If checksum doesn't cover RG, and we want to accept packets from different RG's, there are a few problems. The most serious are avoided by sending only to one RG in any given connection. Replying to any RG that is heard from opens TCP to serious security and reliability holes. 

Proposed Rules for Case of RG-Rewriting, RGs not Checksummed: 

· Accept any source RG on incoming packets and deliver to application. Only use ESD for this. 

· For Active TCP "Open" and all UDP: Application specifies destination RG. Send only to the application's requested RG, but receive from any. 

· For Passive TCP Open: send only to the first RG that arrives during the opening handshake. 

Based on three, if source RG is corrupted, the connection will never open. The passive open side will ack the good SYNs to the corrupt return RG of its peer. The alternatives to this (if we can't have the sender able to checksum its local address's RG) require opening up the TCP handshake logic into three or so special cases, and they also may still have security problems. 

Result: if there is a bit error in the source RG received in TCP LISTEN state, the rescue can only come from a higher layer than TCP. Weighed likelihood of this corruption against the risks of choosing from among several RGs that arrive during the handshake, and decided the best thing to do is recommend that source RGs be known to senders, so they can be included in the checksum. 

Corruption of destination RG is not a problem. Packet will be misdelivered and discarded, retransmission will get to correct site, and connection will open. 

Because of never switching RG, multihomed connection will be broken if RG changes. Also applies to rehoming. 

The approach does help when there are two different RG exit paths and routing changes which causes a different RG to start being used in the middle of the connection. 

Nordmark noted that this makes connection identification easier than existing IPv6 because only need to look at ESD instead of list of possible addresses. Also suggested that it might be worse because sender doesn't know anything changed. 

Future transports could be developed which allow complete separation of RG and ESD that had other connection identification mechanisms, authentication, etc.

V. Conclusions 

Deering asked the group for their overall impression of what people think. 

Mike O'Dell draws several conclusions: 

· He thinks it is unreasonable to move forward with the current proposal. There are a number of things that are worth pursing. There are a bunch of pieces that we think we should do. This has really pushed our thinking about what it means to renumber. 

· Most of the hard questions dealt with impact of renumbering. He is perfectly willing to not go forward with his as main proposal. Thinks we should see what we can extract and move forward. 

Steve Deering: Can we still get some of these advantages with current scheme? 

Mike O'Dell: Long term requirement is to control aggregation topology independent of getting sites to participate. That is the fundamental goal. This proposal does not enable this in toto. There are still other things that need to be done. 

The question is what pieces should we take? 

Jim Bound: Likes some of the parts of GSE, does not like some of current parts of provider based addressing. There are lots of pieces here which are improvements. The main thing he didn't like was the renumbering approach. 

Dimitry Haskin: Agree with Mike that at this point the proposal is not deployable. Too much risk involved. When meeting started he thought it was feasible, but now thinks it is not possible. Should we continue working on proposal as research project? It is not practical for deployment now. Could have a transition mechanism. 

Lixia Zhang: Thinks fundamental problem is renumbering. DNS still needs work. 

Charlie Perkins: Agrees this is too much definition to be done in time for IPv6 deployment. Likes separation of address into ESD and locator. Might make other problems easier in the future. 

John Stewart: Advantage he sees of independent of rewriting packets is aggressive aggregation. This proposal does it by rewriting of addressing. Wondering if there is a middle ground with provider based addressing but changing with [???] Take best pieces of each approach. There are lots of subtle transport issues that we may not understand yet. 

Mike O'Dell: Believes that large structure proposal is a much better model for aggregation than provider based addressing. 

Margaret Forsythe: Thinks the addressing part is inherently useful. Could have something like this, but do not need to take full advantage of this now. New transport protocols could take advantage of protocol.Allison Mankin: A lot of the attractions are ones that we have been striving for in the IPng area. Thinks it would be a shame if we didn't pursue this. Thinks we should pursue some parts of GSE in transitional way. 

Erik Nordmark: Thinks it would be useful to take advantage of ESD's. We could use for connection identification. 

Bob Hinden: Suggested that it is good to require an ESD in all addresses. This may have advantages for multihoming (sites and nodes) and permit new transport protocols to be developed which take full advantage. 

Jim Bound: Will put out draft why renumbering is not important. Location and identification is not going to work for a long time. 

John Stewart: Ramification of large routing tables along with increase with things like multihoming. Reasons why we now need to aggregate from leaf up. Single-homed sites do not need any information about routing (just default), they don't much want any pain to renumber. We should put the work of renumbering in places that need flexibility. Multihomed sites. 

Alex Conta: Thinks current provider based addressing scheme is good. Reason we thought that provider based scheme was thing to do is because we thought there would be problems with separate identification and location. We now have a better view of the costs of renumbering. We should document this. Cost to site, provider, etc. Could also conclude that node-id and locators do not solve the multihoming problem. GSE did seem to provide better form of aggregation. We should continue looking for better forms of aggregation. Conclusions we draw today are the high costs for using GSE to improve aggregation. 

Dimitry Haskin: Does not like requirement to make ESD in all addresses. He is opposed to this. Thinks price of administration is too high. 

Matt Thomas: Likes the ICMP "Who Are You" message and putting it in DNS server.Dan Harrington: Renumbering is hard, we now know better. Need support to support multihoming without breaking aggregation.Matt Crawford: Hope that by 3:30pm we will list topics to pursue. For now, has sense of others in the room, but thinks that it is something that is worth going forward with but don't have time to fully pursue. Should do a few small things now to allow options later. Possibilities: 

· PCB Lookup Rules 

· Pseudo checksum rules 

· "Who Are You" you message 

· 8-byte node id 

· Two faced DNS ? 

O'Dell added: 

· Split records in DNS 

· Revisit provider based addressing model. Problematic. 

· Minimal address is to split

Steve Deering: 

· Keep term "Routing Goop"!!! 

Erik Nordmark: Argument to make two-faced DNS is to isolate site from changes would be to return site local addresses in site to site local communication. Reduces the risk of a failure of renumbering from disrupting site communication. 

Allison Mankin: Should remove "registry" field from provider based addressing. We can work to improve this. 

Steve Deering: TCP depends on its weak security by depending on address providing both location and identification. TCPng could do different things that allow separation. 

Jim Bound: Seconds large structure internet draft. Provider based document was compromise. Thinks we can do better. Agrees about TCP weak security. 

Bob Hinden: Suggested that if connection identification is limited to ESD and pseudo-checksum covers full addresses (essentially providing packet integrity) that it would be easier to support multihomed sites and nodes. TCP would then accept packet sent from any interface of multihomed node and/or received on any interface, but avoids the problems relating to corrupted source addresses. 

Masataka Ohta: Hope that many things can be made to work with GSE. Would like to pursue as an Informational RFC. 

Thomas Narten: Will need a Two-faced DNS if we are using site local addresses. 

Allison Mankin: There should be work done to develop a new transport that could just work with ESD's.

VI. Next Steps 

Steve Deering broke out parts of proposal to see what parts the Working Group could move forward. 

Node ID: Change from 6-bytes to 8-bytes. This would break provider based addressing documents. Discussion about keeping 6-byte MAC or expanding to allow 8-bytes. Deering polled group. Most people thought we should change to make room for 8-byte MAC. 

Brief discussion and poll to put structure in ESD's to allow lookup. Strong consensus to not add structure to ESD's. 

Group initially agreed that low order 8-bytes will be required to be globally unique. This will make it harder for links without built in MAC addresses. 

More discussion followed. It is now less clear that there is a consensus on making ESD globally unique. 

Conclusion is to review the ESD issue at the Memphis IETF. We need more data before we can make a final decision. 

RG Structure: General agreement to rewrite provider based addressing specifications. We can make a number of improvements. 

PCB look-up rules: Document now, but decision depends on making globally unique ID's. Also applies to flow identification, fragment identification, etc. 

Checksum: Don't change pseudo checksum algorithm. Will continue to include full IPv6 source and destination addresses. 

Two-faced DNS is useful for site local address. Work on how to use site local addresses for intra-site communication. 

Summarized into the following table: 

Legend: X = do not adopt 

Y = adopt 

* = needs more study 

X Rewriting by routers 

X Name for Sites & Mapping to/from RG 

* ESD's 

Y RG structure 

* PCB Lookup rules 

X Pseudo checksum rules 

Y 8-byte node ID 

Y Two faced DNS for site local 

Y Resolve DNS via ICMP "Who Are You" 

Y DNS response synthesis 

* Auto-Injection of prefixes into sites 

Y Inter-provider partition healing protocol(s) 

* Use only site-local prefixes for intra-site communication 

* How much of address is AH 

* Flow identification change 

* SA Ident change

VII. Actions Items for Memphis 

Minutes for this meeting, and meeting report / Bob Hinden 

"WhoAreYou" ICMP Message / Matt Crawford 

Modify Link Name Draft / Dan Harrington 

Synthesized AAAA Replies / Jim Bound , Mike O'Dell 

Revised Provider Based Addressing and Addr Architecture / Mike O'Dell and Bob Hinden 

Unique ID's (ESD's) Assignment, Mike O'Dell, Allison Mankin, Matt Thomas 

Experimental Addresses Rewrite: Bob Hinden 

IPoverEthernet/FDDI : Matt Crawford 

IPoverPPP: Dimitry Haskin 

10 Lessons from meeting: Thomas Narten, John Stewart, Allison Mankin, Lixia Zhang, and Matt CrawfordVIII. Work We Think Other People Should Do

Non-corrosive multihoming of sites (partition homing) 

Auto-aggregation of public topology 

Auto-aggregation of site topology 

Auto prefix dissemination in site 

Auto prefix acquisition by sites 

DNS versus Renumbering

IX. Meeting End 

Next meeting will be at the Memphis IETF. Sessions are schedule for Thursday and Friday. 

Current Minutes of the IPng (IPNG) Working Group 

Reported by: Bob Hinden

Agenda 

Thursday 1-3pm

Introduction and Bash Agenda / Steve Deering (5 min) 

Document Status / Bob Hinden (5 min) 

Review of Action Items for Previous Meetings / Bob Hinden (5 min) 

Priority Field / Steve Deering (15 min) 

Conclusions/Results from Interim Meeting / (80 min) 

Meeting Summary / Bob Hinden (5 min) 

Revision to Provider Based Addressing / Bob Hinden (10 min) 

Analysis of GSE Proposal / Matt Crawford and others (25 min) 

IPv6 over Ethernet & FDDI / Matt Crawford (5 min) 

IPv6 over PPP / Dimitry Haskin (5 min) 

IPv6 over ARCNET and LocalTalk / Bob Hinden (5 min) 

The Use of End System Designators in IPv6 / Matt Thomas (5 min) 

Routing Goop and AAAA Records in DNS / Jim Bound (5 min) 

Numbering point-to-point and boundary links / John Stewart (5 min) 

ESD Pro and Con's / Thomas Narten (10 min) 

Friday 9-11:30am 

Conclusions/Results from Interim Meeting Continued / 60min 

Solicited Node Definition / Steve Deering (15 min) 

IPv6 Tunneling Spec and GRE / Steve Deering (15 min) 

Router Renumbering for IPv6 / Matt Crawford & Bob Hinden (15 min) 

Advertising site prefixes in RAs / Erik Nordmark (10 min) 

Prefix Notation / Bob Hinden (5 min) 

Who Are You / Matt Crawford (5 min) 

Inter-Domain Routing Status / Bob Hinden (5 min) 

ND Zero Lifetime advertisement issue / Thomas Narten (5 min) 

Advanced API Spec / Matt Thomas (5 min) 

Moving Base IPv6 Specs to Draft Standard / Steve Deering (5 min) 

Wrap Up and Action Items / Bob Hinden (5 min) 

Thursday 1-3pm

I. Introduction and Bash Agenda / Steve Deering 

Steve Deering introduced the meeting and asked for agenda changes. Request to add slot for Mobile IP and an SNMP issue.

II. Document Status / Bob Hinden 

The following RFC's were published as Proposed Standard: 

· An IPv6 Provider-Based Unicast Address Format , RFC 2073 

· RIPng for IPv6 , RFC 2080 

The IESG Approved for Informational RFC:

· Basic Socket Interface Extensions for IPv6 

IETF Last Calls was completed for: 

· Generic Packet Tunneling in IPv6 Specification 

The IPng document editor submitted to IESG for IETF Last Call: 

· TCP and UDP over IPv6 Jumbograms 

Working Group Last Call was completed for: 

· Header Compression for IPv6 

· IPv6 Router Alert Option 

These will be advance as soon as updated Internet Drafts are published based on the comments received during the last calls.

III. Review of Action Items for Previous Meetings / Bob Hinden 

Action Items from San Jose IETF: 

· Steve Deering will write a description of proposed changes to Priority Field and send to IPng list. 

· OBE based on discussion on IPng list. Need to get closure at Memphis meeting. On Agenda for Memphis. 

· Document editor will send email to IANA to add default hop limit of 64 parameter to IANA registry for IPv6 defaults. 

· Sent on December 12, 1996. Can't find it on IANA web site. Resent on March 12, 1997. 

· Thomas Narten owns getting "IPv6 over Token Ring" issues resolved. 

· Working group last call will be done when new Internet Draft is out. 

· Document editor will do a Working Group last call on BSD API. Goal is to publish an Informational RFC. 

· Sent on December 10, 1996. Working Group last call ended December 24, 1996. A number of comments were received. Will advance to IESG once a new internet draft is available based on comments. Done. Submitted to IESG, IESG approved as Informational RFC. 

· Document editor will submit Tunneling Spec to IESG for proposed standard. 

· Sent request to IESG on December 10, 1996. IESG last call sent on December 30, 1996 that ended on January 17, 1997. Many comments received. IESG restarted last call for this document and two GRE documents on IPv4 tunneling. 

· Steve Deering currently reviewing GRE documents and will respond to IESG last call. This is on the agenda for Memphis. 

· Document editor will do a Working Group last call on Header Compression specification. 

· Sent on December 10, 1996. Working Group last call ended December 24, 1996. Comments received from Thomas Narten. Once comments resolved and new draft published, document editor will send to IESG. 

· Hinden and Deering will propose to the mailing list that the ND solicited node address be changed to fit into a longer prefix. This is on the agenda for Memphis. 

· Steve Deering expected to have a draft on "Multihoming / Source Address Selection" in early 1997. 

Open: 

· Document to do a working group last call on IPv6 Router Alert Option. 

· Last call sent on December 17, 1996. Working Group last call ended on December 31, 1996. One minor comment received. Document editor will send to IESG once new ID is published. 

· Chairs to generate a list of changes that are being considered for the base specifications. 

Needs to be done: 

· Hold an interim meeting to discuss the 8+8 proposal. Done. Held on Feb 27 and 28, 1997. 

· Bob Hinden to write internet draft on his Router and Networking Renumbering proposal. 

· Matt Crawford volunteered to write draft. Done. Draft written and on Memphis agenda. 

· Dimitry Haskin and Dave Katz to write a draft proposing the addition of an option to BGP4 to carry IPv6 interdomain routes. 

· Drafts written for BGP+ and BGP5. IDR discussed. Compromise discussions underway. 

· Bob Hinden to add to the addressing architecture document prefix notation. 

· Work underway. Expect to have new draft by ID deadline. Done. Draft published. 

· Thomas Narten to include in next update of neighbor discovery a rule to silently drop non-DAD packets that use the unspecified address as the source of the packet.

Action Items from Interim Meeting: 

· Minutes for Interim meeting, and meeting report / Bob Hinden. Done. Sent to IPng list and installed on IPng web site. 

· "WhoAreYou" ICMP Message / Matt Crawford. Draft missed ID deadline. Sent to IPng list and on Memphis agenda. 

· Modify Link Name Draft / Dan Harrington. Update underway. 

· Synthesized AAAA Replies / Jim Bound , Mike O'Dell. Done. Jim Bound to write draft. 

· Revise Provider Based Addressing Architecture / Mike O'Dell and Bob Hinden. Work started. Proposal on Memphis agenda. 

· Unique ID's (ESD's) Assignment / Mike O'Dell, Allison Mankin, Matt Thomas. Done. Matt Thomas submitted draft. On Memphis agenda. 

· Experimental Addresses Rewrite: Bob Hinden. Waiting for Provider Unicast Formats to settle a bit more. 

· IPoverEthernet/FDDI / Matt Crawford. Done. Internet Draft published. 

· IPoverPPP / Dimitry Haskin. Done. Internet Draft published. 

· Lessons from meeting / Matt Crawford, Allison Mankin, Thomas Narten, John Stewart, Lixia Zhang. Done. Internet Draft published. Discussion on agenda.

IV. Priority Field / Steve Deering 

Discussion on mailing list, but did not reach consensus. Current proposal is: 

· Declare that 4-bits of Priority are re-writeable by routers/ISPs for private purposes (and exclude from authentication header). 

· Priority bits have no significance to receivers. 

· Convention: Sender sets low order bit to mean interactive traffic. 

· Delay more important than throughput. 

· Suggests that routers/ISPs use other bits before touching the "interactive bit." 

· Effects queuing only, not routing (since re-writeable). 

After email discussion, Deering still thinks that proposal is correct. 

Charlie Perkins: If left undefined and people do use them, it might be hard to define them later. 

Nordmark: Could anyone modify in transit? Yes. 

Narten: How many bits do router vendors want? Also, thinks it is important to not have interactive bit rewritten to preserve function. 

John Stewart: Thinks one bit is enough for interactive traffic, but more bits will be needed for additional services. He thinks making bits an integer field instead of individual bits would be better. 

IPSEC had proposed not including the whole first four bytes of the IPv6 header from authentication. This is in the latest AH draft. Would give us more flexibility. 

John Stewart: If we define now, would preclude different usage in future. 

Nordmark: Should define what host does to these bits when sending, and how it should handle these bits when receiving. Need to do this first. 

Mike O'Dell: Likes the proposal. Thinks it is best he had heard in discussion. 

Changing version field will break header compression. 

Matt C.: Good to define default action for hosts now, routers could use them differently later. Need this to define application behavior. 

Deering took poll. More were in favor. Group will go forward with this proposal in next version of base IPng specification. Important to make sure AH is consistent. First 32-bits of header should not be included in authentication computation.

VI. Conclusions/Results from Interim Meeting 

Meeting Summary / Bob Hinden 

Deering talked and showed table of results from interim meeting. Summarized into the following table: 

Legend: X = do not adopt 

Y = adopt 

* = needs more study 

X Rewriting by routers 

X Name for Sites & Mapping to/from RG 

* ESD's 

Y RG structure 

* PCB Lookup rules 

X Pseudo checksum rules 

Y 8-byte node ID 

Y Two-faced DNS for site local 

Y Resolve DNS via ICMP "Who Are You" 

Y DNS response synthesis 

* Auto-Injection of prefixes into sites 

Y Inter-provider partition healing protocol(s) 

* Use only site-local prefixes for intra-site communication 

* How much of address is AH 

* Flow identification change 

* SA Ident change 

Shows which items were agreed to do, not to do, and which need more study.

VII. Revision to Provider Based Addressing / Bob Hinden 

New draft will be called "Aggregation-Based Unicast Address Formats." This was an output of the Interim meeting. This will replace RFC-2073 "An IPv6 Provider Based Unicast Address Format" Goal is to provide additional flexibility based on O'Dell GSE Draft. Changes include: 

Remove Registry field 

Base Design around Large Structures 

Structures 

_______________ _______________ 

/ \+--------------+/ \ 

( P1 ) +----+ ( P3 ) 

+\_______________/ | |----+\_______________/ 

| +--| X | 

| _______________ / | |-+ _______________ 

+/ \+ +-+--+ \ / \ 

( P2 ) / \ +( P4 ) 

\_______________/ / \ \_______________/ 

| / \ | | 

| / | | | 

| / | | | 

_|_ _/_ _|_ _|_ _|_ 

/ \ / \ / \ / \ / \ 

( S.A ) ( S.B ) ( P5 ) ( S.D ) ( P6 ) 

\___/ \___/ \___/ \___/ \___/ 

| / \ 

_|_ _/_ \ ___ 

/ \ / \ +-/ \ 

( S.E ) ( S.F ) ( S.G ) 

\___/ \___/ \___/ 

The Aggregation-Based Address Format is designed to support both long-haul providers (shown as P1, P2, P3, and P4), interchanges (shown as X ), multiple levels of subscribers (shown as S.x) and providers (shown at P5 and P6). Interchanges (unlike current NAP, FIX, etc., connection points) will allocate IPv6 addresses. Providers who connect to these interchanges will also subscribe for long-haul service from one or more long-haul providers and achieve a certain degree of addressing independence from long-haul transit providers. 

Format 

| 3 | 13 | 32-bits | 16-bits | 64-bits | 

+---+-------+---------------+-----------+-----------------------+ 

|010| TLA | NLA* | Subnet | Interface ID | 

+---+-------+---------------+-----------+-----------------------+ 

<-----Public Topology-------> Site 

<-----------> 

Topology 

<--Interface Identifier-> 

Fields 

FP Format Prefix (010) 

TLA Top Level Aggregator 

NLA* Next Level Aggregator(s) 

SUBNET Site Specific Topology 

INTERFACE ID Interface Identifier 

Top Level Aggregator 

Top Level in Addressing Hierarchy 

Assigned to Organizations providing Public Transit Topology 

Not to Private Transit Topology 

Supports 2^^13 TLA's (8K) 

Additional available by using another FP 

IANA Assigns Blocks to Registries 

Registries assign to TLA's 

Registries get more from IANA 

Next Level Aggregator 

Used by TLA's to: 

· Create TLA Hierarchy 

· Identify Sites 

· TLA's may support NLA's in their own Site ID space 

· NLA's may support NLA's in their... 

· Works exactly like CIDR delegation 

· TLA's assume registry duties for NLA's 

NLA* 

+-----+------------------+--------+-----------------+ 

|NLA1 | Site | Subnet | Interface ID | 

+-----+------------------+--------+-----------------+ 

+-----+------------+--------+-----------------+ 

|NLA2 | Site | Subnet | Interface ID | 

+-----+------------+--------+-----------------+ 

+-----+------+--------+-----------------+ 

|NLA3 | Site | Subnet | Interface ID | 

+-----+------+--------+-----------------+ 

Proposal was generally well accepted. There was some discussion about fixed boundaries in these addresses, particularly about the TLA boundary. This was clarified that it is only there for address allocation and is not visible by the routing system. 

Bob Hinden will write an internet draft for "Aggregation-Based Unicast Address Formats."

VIII. Analysis of GSE Proposal / Matt Crawford and Others 

Most topics will be outcome of PAL1, some were the result of additional analysis. 

Motivation for GSE 

· Renumbering must happen to achieve and maintain the necessary aggregation to keep routing computation feasible. 

· Make intra-site communication impervious to global renumbering 

· Make renumbering easier to do 

· Put the routing cost of multi-homing onto the parties involved. 

GSE Mechanisms 

· Conceal global-scope prefixes from the sites' interiors. 

· Insert source prefix at exit/remove destination prefix at entrance 

· Fixed boundaries in addresses 

· Modifications to checksum, PCB/SA lookup rules 

· Globally unique identifiers for nodes 

· DNS magic 

· Two-faced DNS 

· AAAA synthesis from parts 

· AAAA synthesis from parts 

· RG upward indirection 

· Multiple providers set up fallback tunnels to create the illusion that failed links are up 

· "Hole-punching" is confined to consenting parties. 

Major Difficulties 

· Due to host ignorance of prefixes 

· New failure modes due to RG not covered by checksum. 

· Can't construct source routes (in general). 

· Hosts can't influence traffic handling by source address selection. 

· Interior routing fluctuations cause source address to thrash 

· Any node that is a tunnel endpoint must act as a border router. 

· Due to DNS modifications 

· Delegation problem: the one who holds your glue is not the one who changes your prefix. 

· No visible solutions 

· Two-faces DNS is required 

· Might be solvable 

· Due to source address rewriting 

· Multicast packets duplicated at multiple site exits. 

Recommendations 

· Do not hide the global prefixes from the interior nodes. 

· There has to be an overlap period (on the order of days to weeks) during prefix reassignments. 

· Define boundaries in addresses 

· Between global and site topology 

· Between routing and node designator 

· Address architecture must be improved for better aggregation. 

· Using site-local addresses can help quite a lot 

· Work on two faced DNS (the alternative is address selection rules for hosts) 

· Globally unique end-system designators have potential uses 

· But arenít panaceas. 

· The next address architecture document should accommodate an 8-byte unique ESD. 

· Candidate: IEEE EUI-64.

Question: What does "accommodate" mean? Does it mean requiring globally unique now? Yes. 

Implications 

· Need to work on Two-faced DNS 

· Need to study coordination between renumbering and updating DNS delegations 

· Root DNS servers at fixed addresses, globally host-routed? 

· Hosts will do source address selection, even if only by default. 

· Boundaries in global addresses facilitate the use of site-local addresses. 

Questions: Should we also work on source selection algorithms? Yes, we should be comparing the two approaches. 

O'Dell raised difficulty with scaling when hosts have many addresses. Doesn't think this will scale. 

Do the recommendations mean that I can't use prefix ::1? Yes, that would not be allowed. 

Starting off a connection with site-local addresses may become inconvenient if one end later goes mobile off-site. 

Could some hosts simply not have site-local addresses? 

Globally unique ESD's preclude routing prefixes of 64 < length < 128 

Or do they? If you have an aligned blocks of ESD's 

What's the ESD of an anycast address? 

Comment that Anycast do not need globally unique, but need ESD which do not conflict with any real ESD. 

Question and discussion about stability of dialin assigned addresses. 

Lixia Z: Question about what it means to require global unique ESD's. 

Comment about getting more feedback from DNS "experts." Agreement that we need more overlook. Need more coordination. 

M. Ohta: Asked why did we look at only rewriting destination locator (based on his proposal of about six months ago). Wants to be able to rewrite destination RG. Could preserve original address in source route header.

IX. IPv6 over Ethernet & FDDI / Matt Crawford 

· Changes to accommodate ESD's 

· Prefix for stateless auto-config must be /64 

· Auto-config address token is EUI64 

· Link-local address token is EUI64 

· EUI-64 is derived from MAC address 

· 00--8-55-12-34-56 -> 0008:55FF:FE12:3456 

· http://standards.ieee.org/db/oui/tutorials/EUI64.html

X. IPv6 over PPP / Dimitry Haskin 

Change to make PPP support 64bit interface ID. Now reserves this size token. No changes to date to accommodate global token. Pending outcome of global ESD issue.

XI. IPv6 over ARCNET and Localtalk / Bob Hinden 

Hinden mentioned both ARCNET and local talk do not have IEEE addresses in hardware and would need some mechanism to get global identifiers.

XII. The Use of End System Designators in IPv6 

IEEE/ANSI EUI Formats 

EUI-64 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| | | | | | | | | | | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---- company_id -------><-------------vendor supplied id ------> 

IEEE 802 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| | | | | | | F | F | F | E | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<------- OUI ---------> <--- vendor id --------> 

FiberChannel 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| | | | | | | ? | | | | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---- company_id -------> <-------vendor supplied id --------> 

Hard problem is what if you do not have an IEEE address in system. 

IANA EUI Formats 

IPv4 Address 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| 0 | 0 | 0 | 0 | 5 | E | 1 | 0 | C | 7 | 5 | 1 | D | C | 9 | D | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---- company_id -------> <-IPv4 Addr (199.81.220.157) ---> 

ASN 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| 0 | 0 | 0 | 0 | 5 | E | 2 | 0 | | | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---- company_id -------> <--- ASN -------><--- Assigned -> 

PPP servers could use IANA OUI and IPv4 address. 

Can not use private use IPv4 addresses 

Use company ID and Autonomous System number (ASN) 

Comment that companies do not normally get ASN numbers. Only assigned to organizations that are multihomed. 

Random ESD Format 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| | 2 | | | | | | | | | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---> <-------------------------------------------------------> 

60 Random bits 

<---> Fixed 4 bits (locally administrated address space 

which is not used by IEEE 

IPv4 addresses in IPv6 

IPv4 Compatible 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | | | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---- company_id -------> <------ IPv4 Address -----------> 

IPv4 Mapped 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

| 0 | 0 | 0 | 0 | F | F | F | F | | | | | | | | | 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 

<---- company_id -------> <------ IPv4 Address -----------> 

IPv4 compatible are OK 

IPv4 mapped have a problem because conflicts with other assignments.

XIII. ESD Pro and Con's / Thomas Narten 

Main Benefit 

· Automatic/transparent deliver of packet to transport endpoint, even if source or destination "Routing Stuff" changes (see below). 

· Transport endpoints are TCP, UDP, IPSEC, etc. 

· Facilitates retroactive fix up of Routing Stuff. 

· Mobile nodes says, "I just moved" here is my new address." 

· During renumbering: "Here is my new preferred address." 

· Required authentication prior to changing "routing stuff." 

Cons 

· Automatic delivery defined above simplifies implementation, but does NOT provide new functionality: 

· Functionality required: IPv6 destination option that says, "use this address when de-multiplexing instead of address in IPv6 header." 

· IPSEC AH provides assurance that option is not a hijack attempt. 

· Basic idea has been proposed before 

· Context identifier parameter" in Huitema's "Multihomed TCP" Draft. 

· "Source identifier Option" in Bound/Roque "IPv6 Anycasting Service" draft. 

· ESD uniqueness requirement adds complexity Intruders guarantee that ESD can not be assumed unique, even if we design them to be 

· New denial-of-service attacks possible: 

· Intruder host "borrows" ESD of dilbert.foo.com, opens TCP connection to www.bar.com 

· Real dilbert.foo.com opens TCP connection to www.bar.com (using same port number) 

· Packets from both connections delivered to same TCP endpoint on web server 

· Second connection (real Dilbert) "loses" 

· Can't defend against without requiring authentication. 

· Need way of dealing with devices that have no IEEE MAC address. Solution possible, but may require some manual configuration. 

· Accidental misdelivery of packet to wrong machine that is using same ESD may trigger dangerous error responses. 

· Disallows small subnets 

· Anycast address need ESD that doesn't conflict with existing ESD (solutions possible, misconfiguration possible) 

My opinion 

· Key issues: compare benefits against cost. 

· There are real costs, some which are not fully understood. 

· Supposed benefits oversold. 

· Considered big picture, benefits not worth the cost.

XIV. Mobile IP / Dave Johnson 

Mobile IPv6 

· Allows transparent roaming of IPv6 mobile nodes 

· Routing to mobile node regardless of its current point of attachment to the Internet. 

· Mobile node is always addressable by its "home agent." 

· High-level overview of operation 

· Care-of addresses from IPv6 address auto-configuration 

· Mobile node sends its own Binding Updates 

· Used for correspondent nodes and home registration 

· Nodes cache binding in a Binding Cache 

· Correspondents route own packets directly to mobile node 

· Current draft is <draft-ietf-mobileip-ipv6-02.txt> 

Dynamic Home Agent Address Discovery 

· Mobile node may not always know its home agent address 

· While mobile node is away from home 

· Home network may need to be reconfigured 

· Different machine may take over as home agent 

· In Mobile IPv4 

· Mobile node can send to "directed broadcast" address 

· All home agents in home network receive request 

· All reject, giving their own unicast addresses 

· Mobile node tries again with one of these addresses 

· Can't do this in Mobile IPv6 since no broadcast in IPv6 

Home Agent Discovery Proposal #1 

· To register when don't know own home agent address 

· Mobile node sends "home agent discovery" packet to home network router "anycast" address 

· Probably an ICMP message 

· By IPv6, received by one border router on home network 

· Router receiving packet multicasts "home agent discovery" into home network to "all home agents group" 

· Home agent returns reply with its IP address to mobile node 

· Mobile node registers to that IP address 

· Implementation would be required in ALL IPv6 routers 

Proposal #2 

· Define "home agent anycast" address 

· Prefix defines which subnet 

· Bottom part could be all-ones (instead of all-zeros) 

· For home agent discovery 

· Mobile node sends request to home agent anycast address for home network 

· Request answered home agent, giving unicast address 

· Mobile node registers to that IP address 

· Implementation of this would be required in ALL IPv6 routers

Comments, Please 

Need feedback from IPng working group 

Send to mobile-ip@smallworks.com (mobile IP mailing list) 

Topologically Correct Addressing 

Packets sent to a mobile node: 

· Source address = correspondent node address 

· Destination address = mobile node care-of address 

· Routing header = mobile node home address 

· (Problem: size of Routing header in every packet) 

· Packets sent from a mobile node 

· Source address = mobile node home address 

· Destination address = correspondent node address 

· Problem: ingress filtering drops all of these packets! 

Proposed Solution: Source Address Remapping 

· Mobile node uses care-of-address as source address. But only while packet on its way to the destination node 

· At the sender: 

· Sender builds packet using home address 

· Then substitute care-of address as source 

· Makes packet source address topologically correct 

· At the receiver (only the end destination node) 

· Receiver substitutes correct source address (home address) back into packet in place of care-of address. 

· Implementation of this would be required in ALL IPv6 routers 

Source Addressing Remapping Method #1 

· Two source addresses in "every" packet 

· Carry real source address in a destination option 

· If present, receiver substitutes into IP header before passing it to the transport layer 

· Used for receipt of this packet only 

· Option creates no state in the receiver 

· Option does not affect any routing from receiver 

· Option is authenticated if packet itself is authenticated 

· Otherwise, no extra authentication needed. 

SAR, Method #2 

· One one-source address (the care-of address) in packet 

· Also a bit in every packet: "source is a care-of-address" 

· Bit probably encoded by presence/absence of a destination option 

· Could also be bit in header or bit in source address 

· Receiver caches <care-of address, home address> mappings 

· If bit set in received packet and no cache entry: 

· Receiver request mapping form care-of address 

· Reply MUST be authenticated 

· Receiver saves original packet and processes after reply 

· Request/reply is probably ICMP 

There was some discussion and will be continued on mailing list.

XV. Synthesis of DNS AAA and RG Resource Records / Jim Bound 

Motivation 

· IPng Working Group PAL1 interim meeting on alternative addressing architecture 

· Add connotation of location and identifier to DNS Resource Record "syntax" for future use. 

· Avoid alteration to DNS protocol and APIs for IPv6 

· Adjunct to other Interim meeting action items 

· Determine initial affect to applications and DNS syntax and processing. 

Processing Model 

· No change to the DNS protocol 

· Client resolve still requests AAAA records in query (e.g., gethostbyname2()), using ESD address 

· DNS server synthesizes from ESD address an AAAA record for each RG record associated with an aAA ESD 

· DNS returns in query response one AAAA record for each RG + aAA pair synthesized at the DNS server. 

· Transparent to client applications during the query operations. 

New aAA and RG Types 

foo.bar.com IN aAA aa:bb:cc:dd:ee:ff:01 /* ESD */ 

IN RG 5f09::/?? 

IN RG 5f08::/?? 

To be Determined 

· RG and ESD length, semantics, and uniqueness. 

· Processing cached AAAA records for resolvers 

· Affects RFC 1886 and DHCPv6 extensions 

· Dynamic updates to DNS must deal with granularity of aAA and RG records 

· Reverse DNS processing is TBD.

XVI. Numbering Point-to-Point and Boundary Links / John Stewart 

If global ESD's, mask lengths will be either up to 64 or 128. Nothing in between. 

Notion that like in IPv4, with current form of interconnects, some global RG would have to be assigned to interconnects (e.g., NAP, etc.). 

Friday 9-11:30am

I. Solicited Node Definition / Steve Deering 

Issue is wanting to avoid a many to one mapping to Ethernet multicast addresses. Don't want to have collisions. L2 filtering, etc. 

Proposal was to allocate IPv6 multicast addresses to not have multicast group > 32-bits. ND solicited addresses conflict with this approach. 

Currently: FF02::1:xxxx:xxxx 

Proposes: FF02::1:FFxx:xxxx 

Working group agreed to adopt change. Will go into Addressing Arch and ND drafts. New addressing architecture with new solicited node definition soon because ND and IPoverFoo need to copy definitions.

II. IPv6 Tunneling Spec and GRE / Steve Deering 

IPv6 tunneling spec has gone through IPng last call and IETF last call twice. IESG want to form a working group to resolve the number of differently tunneling specs. GRE IPv4 specs submission has caused IESG to take a deeper look. One of the original IPng working group requirements was to define IPv6 tunneling. We only want one tunneling specification for IPv6. 

Alex Conta: GRE specification is not ready for an IPv4 specification because it is not complete. It does not cover IPv6 tunneling as currently written. Specs are not complete. 

Jeff Burgen / AD: IESG has decided to look at tunneling overall. Will be resolved too quickly. The new group will be in the internet area. The AD's will scope work. Doesn't want it to drag on a long time. 

Deering suggested that IPv6 need not be in that charter of this group. IPv6 already has one specification. 

IPng Chairs will write a strong note to IESG requesting IPv6 not be included in this new working group and concern about the delay to existing IPv6 work.

III. Router Renumbering for IPv6 / Matt Crawford 

Internet draft written by Matt Crawford based on presentation at previous IETF by Bob Hinden. 

Router Renumbering (RR) Packet contains: 

· Anti-replay fields 

· Zero or more Prefix Control Operations (PCOs), each of which has: 

· [missing remainder of slide] 

· RR Message Processing 

· Check for valid sequence number 

· Optionally check for valid replay 

· Verify authentication 

· For each PCO 

· For each interface 

· For each address and/or Prefix on that interface 

· Compatible to MatchPrefix, if it matches, 

· Perform operation 

· Do not create duplicate prefixes 

Why not use SNMP? 

· Multicast 

· Renumbering will be "more fundamental" than other management functions 

· Security 

Why not use IPSEC for Authentication? 

· SA is looked up by SPI + destination address, but destination addresses are changing during RR. 

· No dynamic key negotiation protocol for multicast destination (correct me if I am wrong) 

Based on discussion will change draft to HMAC SHA1. Jim Bound mentioned that new docs need to require method for key selection. 

Open Issues: 

· More than one match on a single interface 

· Repeat operation on each match 

· Require duplicate suppression, or advise against construction of non-idempotent combinations? 

· All-routers multicast address is currently only defined at node- and link-local scope. Site- or org-scope would also be useful. 

· Asymmetric authentication scheme might be more appealing 

· No attempt to distribute information for RA fields other than Prefix information (e.g., hop limit.) 

Nordmark: Thinks this is a good idea. We should be careful not to include things that could break things. Would be better to make it harder to keep things from breaking. Might require more elaborate mechanisms and/or procedures. Need to be careful to make it harder. 

Next Steps: 

· Update draft to use HMAC and finish missing sections. 

· Think about Nordmark suggestions.

IV. Advertising Site Prefixes in RAs / Erik Nordmark 

Announcing Site Prefixes in Router Advertisements 

Goals: 

· Limit effect of renumbering by ensuring that traffic local to the site use site-local addresses 

· Do this without requiring a two-faced DNS (i.e., no site local in the DNS) 

Proposal: 

· Advise the global prefixes (with lifetimes) for the site in ND messages

· The host use this info to maintain a list of the current site prefixes 

· The host resolver (gethostbyname function) checks against list of prefixes after resolving the name. 

· When one of the addresses retrieved from the DNS matches one of the site prefixes (i.e., the first N bits match), then add the corresponding site-local address to the front. 

[slides showing how to encode in prefix advertisements] 

[missing remainder]

V. Prefix Notation / Bob Hinden 

Prefix notations was added to current draft of addressing architecture document. General form proposed is: ipv6-address / prefix-length 

Examples: 

12AB:0000:0000:CD30:0000:0000:0000:0000/60 

12AB::CD30:0:0:0:0/60 

12AB:0:0:CD30::/60 

12AB:0:0:CD30/60 

It included a notation (shown in last example) to not require "::" at the end of the prefix. Implied left justifying prefix and zero fill remainder. General consensus of group was that this added complexity and to not support this (e.g., require "::").

VI. Who Are You / Matt Crawford (5 min) 

Motivation 

· GSE would have made it difficult to have reverse lookup domains. 

· IN=ADDR.ARPA poorly maintained, will IP6.INT be better. 

· Maintenance of delegations will be more difficult in the expected frequent-renumbering environment of "THE FUTURE." 

· For access control, or even logging, IP6.INT provides nothing but a hint anyway. 

History 

· Experimental RFC by W. Simpson, "ICMP Domain Name Messages", RFC 1788. 

Format of Packet 

ICMP Message: 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Type | Code | Checksum | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| ID | unused | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| | 

+ Cookie + 

| | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Time-To-Live | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| NameLen | FQDN ... | 

+-+-+-+-+-+-+-+-+ + 

/ / 

+ + 

| | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Fields: 

Type TBA1-FQDN Query (more pronounceably known as Who-Are-You or RU). TBA2-FQDN Reply (possibly to be known as Sam-I-Am).

Code For FQDN Query, always zero. For FQDN Reply: 

0 Indicates that the Time-To-Live field is meaningful 

Indicates that the responding node cannot provide a meaningful TTL for its Address-to-FQDN association. 

Checksum The ICMPv6 checksum. 

ID A 16-bit field to aid in matching replies and requests. Its value is chosen by the querier and copied from a Request to a Reply by the responder. 

Cookie An opaque 64-bit field to aid in avoiding spoofing. Its value is chosen by the querier and copied from a Request to a Reply by the responder. 

Time-To-Live 

The number of seconds that the name may be cached. For compatibility with DNS [1035], this is a 32-bit signed, 2's-complement number, which must not be negative. 

NameLen The length in octets of the FQDN, as an 8-bit unsigned integer. 

FQDN The fully qualified domain name of the responder, as a sequence of NameLen US-ASCII octets, with periods between the components. 

The last three fields (Time-To-Live, NameLen and FQDN) are not present in the FQDN Query. 

Steve Deering: Wondered about supporting multiple names in packet? 

Alex Conta: How different form DNS? Simpler fewer options/etc. Intended only for reverse lookups. 

Usage and Issues: 

· The internet could easily get clogged with these messages. Therefore, this could be a back-end to DNS servers, which would catch the answers. 

· What's a good TTL when the responder can't provide one? 

· What about a timeout for negative caching? 

Question about viability of current reverse lookup database. Questioner thought premise was untrue. Thought was getting better. Response was that with renumbering this would get even harder to maintain. This mechanism does not require manual configuration of a database. Important to keep this simple. 

Features: 

· PLUS: Routing system takes the place of IP6.INT delegation 

· Always current 

· PLUS: A Meaningful TTL is usually available from Autoconf. or DHCP. 

· MINUS: Target must be up and reachable to do a lookup 

· But is it meaningful to say a certain FQDN is associate with an address when it isn't? 

Comment. Dialin users do not know their name. DHCP could tell host their domain name when they get the address. Could also return with a empty name length. What about negative caching?

VII. Inter-Domain Routing Status / Bob Hinden 

Covered in document status.

VIII. ND Zero Lifetime advertisement issue / Thomas Narten 

Denial-of-Service Vulnerability in Stateless Addrconf 

Attack: 

· Intruder connects to local link (remote access not sufficient). 

· Listen for RAs, determine what prefixes are in active use. 

· Send out a single RA, advertise in-use prefix(es) with lifetime of zero. 

Consequence: 

· Receiving host immediately invalidates address(es) formed via stateless autoconf for the specified prefix(es). 

· Host immediately terminates all transport layer connections (addresses) in use no longer exists). 

· Every host acts on received RA, entire network effectively brought down. 

· Subsequent RA containing correct (no zero) Lifetime does not undo damage.

One Possible Solution: 

· When a prefix lifetime reaches zero, host enters DELAY state, doesn't actually invalidate for two additional hours. 

· Receipt of subsequent lifetime value > zero cancels DELAY state 

· While in DELAY state, silently ignore additional Lifetime values of zero (for receiving prefixes) 

· Result: Intruder's zero Lifetime advertisement effectively ignored; subsequent RAs from real router cancel intruders RA before DELAY state expires. 

Question for Working Group? 

· Is this significant threat? 

· Is the cost of fixing vulnerability small enough to justify? 

· Should we fix problem? 

There are plenty of denial-of-service vulnerabilities already: Why fix this one given the others? 

· Other attacks must target individual hosts, one at a time. 

· Other attacks disrupt first-hop path, not the hosts themselves. 

· When intruder leaves, path is restored; host may be able to continue. 

· TCP connections break on a timeout, which takes several minutes 

· Doing long-term damage require long-term presence of intruder (increasing likelihood they will be discovered). 

· Vulnerabilities in IPv6 are analogous to those in IPv4 (i.e., IPv6 doesn't make problem worse than what we have today). 

· In contract to IPv4, IPv6 zero lifetime attack: 

· All hosts process single packet in the same way. 

· Host actively terminates all existing transport connections immediately, no recovery possible. 

· IPv4 has nothing like this; IPv6 has introduced a vulnerability not present in IPv4. 

Suggestion that before invalidating prefix, send a RS and see if RA is consistent with message which invalidated prefix. There was discussion and additional suggestions. General consensus to fix vulnerability but there are issues with proposed mechanism. Author will propose to mailing list.

IX. Advanced API Spec / Matt Thomas 

Any last comments, authors would like to issue working group last call. Document editor will do a working last call for Informational RFC.

X. SNMP Issues / Margaret Forythe 

Couple of issue with current MIB drafts and discuss solutions. 

IPv6 MIB Issues 

· Separate TCP/UDP tables for IPv4 and IPv6 

· No way to represent an IP address in a MIB that can be ether IPv4 or IPv6. 

· Various Nit's 

· IP Routing table updates 

· IPv6IfIndex as index in TCP/UDP Tables 

Possible Solution(s) 

· Unified IP Address format 

· Single UDP &TCP Tables for IPv6 & IPv4 "connections" 

· Minor MIB cleanup 

Unified IP Address 

· Type/version in IP address type? 

· Octet string or OID? 

· SMI Change or Textual conv. 

· SMI change (new App. type) allows type discrimination in SNMP packet. 

· SMI change does not permit backwards compatibility to current managers/agents. 

· SMI change may be politically difficult 

· Display hints in textual convention do not give info to mgr. unfamiliar with particular MIB. SMI App types do. 

UnifiedIPAddress::= textual convention 

DISPLAY HINT "X" (?) 

STATUS current 

DESCRIPTION 

"IP Address type for both IPv4 or IPv6 addresses. Particular type can be determined from length. Length of 4 = IPv4; 16 = IPv6. Addresses are stored in network byte order. IPv4 addresses should be displayed as with display hint "1d.:; IPv6 addresses as with "2x:"." 

SYNTAX OCTET STRING (SIZE (4 | 16)) 

SMI Applications Type - 

UnifiedIPAdress ::= 

[APPLICATION 7] 

IMPLICIT OCTET STRING (SIZE (4|16)) 

Will work with MIB author to resolve issues. When new drafts are out, IPng Document Editor will issue Working Group last call to move the draft to Experimental Status.

XI. Destination Locator Rewriting / Masataka Ohta 

Motivation 

· Protocol Modifications 

· Don't checksum-protect destination locator. 

· Modify routing header (with authentication) to Preserve the Original Locators. 

· PCB lookup with Source and Destination ESDs (both Checksummed). 

Modifications to Routing Header 

· Add address[0] to contain the first destination address 

· Extra 16-byte in header 

· Copy, don't swap 

· Faster operation expected 

· Same level of security

[slide showing change to pkt format] 

Comment: This looks like what Dave Johnson is proposing for mobile IP. Might be able to combine?

XII. Global ESD Proposal / Bob Hinden 

Presented a proposal that would keep open the option for future transport protocols to use global ESD. Proposal was as follows: 

· Require all Interface ID be constructed using EUI-64 framework. Easy for both for devices which have hardware 48-bit MACs and with the use of the IANA or vendor specific prefix, easy for serial lines, tunnel interfaces, localtalk, etc. Only cost is use of 64-bit ID's. 

· Part of EUI64 is a bit which says if the address has global scope (uniqueness). We require that bit be set correctly. EUI-64, which is built from hardware MAC, will be global. Serial lines, tunnel end points, localtalk, etc. will not. 

· We do not make any change to current TCP/UDP connection identification, pseudo checksum, etc. Current transport protocols will treat all addresses as opaque 128-bit quantities. 

· New transport protocols and/or research projects can tell if the destination with which they are about to communicate has an address with a global identifier when they get the results of a DNS lookup. If so, then can do whatever ESD magic they want. In practice, many (most?) interface ID's will be global. 

This proposal would "keep the door open" for global ESDs but limit the impact now. The only cost now is requiring 64-bit interface ID and setting the global scope bit correctly. 

Considerable discussion resulted. Chairs polled the working group: 

0 voted for global ESDs in IPv6 

7 voted for no global ESD in IPv6 (e.g., keeping current interface ID behavior) 

33 voted for proposal to use EUI-64 global/local bit to identify if interface ID is global. 

This is a rough consensus to adopt this approach. Will be added to addressing architecture document. 

Slides

None Received Attendees List

Attendees List

TOC