2.3.10 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 28-Oct-97

Chair(s):

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

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

Mailing Lists:

General Discussion:ipng@sunroof.eng.sun.com
To Subscribe: majordomo@sunroof.eng.sun.com
In Body: in body: subscribe ipng
Archive: ftp://playground.sun.com/pub/ipng/mail-archive

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

Done

  

Submit extended IPng specifications as Internet-Drafts.

Done

  

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

Done

  

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

Done

  

Submit revised IPng specifications as Internet-Drafts.

Done

  

Submit final IPng specifications to IESG for consideration as Standards.

Aug 97

  

Submit revised specifications to IESG for Proposed Standard. Includes Aggregatable Unicast Formats, IPv6 over Ethernet, IPv6 over FDDI, IPv6 over Token Ring, IPv6 over PPP, Header Compression, etc.

Aug 97

  

Submit updated core IPng Specifications to IESG for Draft Standard. Includes: Protocol, Addressing Architecture, Addressing Documents, ICMP, Neighbor Discovery, Address Auto Configuration, DNS, etc.

Jan 98

  

Submit IPng specifications at Proposed Standard to IESG for advancement to Draft Standard.

Jun 98

  

Submit IPng specifications at Draft Standard to IESG for advancement to Standard.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1886

PS

DNS Extensions to support IP version 6

RFC1885

PS

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

RFC1884

PS

IP Version 6 Addressing Architecture

RFC1887

 

An Architecture for IPv6 Unicast Address Allocation

RFC1897

E

IPv6 Testing Address Allocation

RFC1981

PS

Path MTU Discovery for IP version 6

RFC1970

PS

Neighbor Discovery for IP Version 6 (IPv6)

RFC1972

PS

A Method for the Transmission of IPv6 Packets over Ethernet Networks

RFC1888

E

OSI NSAPs and IPv6

RFC2019

PS

Transmission of IPv6 Packets Over FDDI

RFC2023

PS

IP Version 6 over PPP

RFC2073

PS

An IPv6 Provider-Based Unicast Address Format

RFC2133

 

Basic Socket Interface Extensions for IPv6

RFC2147

PS

TCP and UDP over IPv6 Jumbograms

Current Meeting Report

Minutes of the IPNG WG

Chaired by Steve Deering (Cisco) and Robert Hinden (Ipsilon).

Reported by Robert Hinden.

Agenda

Monday, December 8, 1997, 1530-1730, (Empire Room)

Introduction / S. Deering (5 min)
Review Agenda / S. Deering (5 min)
Document Status / R. Hinden (10 min)
Status of moving base specs to Draft Standard / R. Hinden (5 min)
TLA/NLA Assignment Rules Status / R. Hinden (15 min)
Resolve Neighbor Discovery and Addr Conf issues / T. Narten (20 min)
Interface Identifier Global Flag / S. Deering (10 min)
Mobile IPv6 Status / D. Johnson (10 min)

Thursday, December 11, 1997, 0900-1130, (Empire Room)

IPv6/NBMA Status / G. Armitage (10 min)
IPv6 over PVC ATM / K. Yamamoto (10 min)
Router Renumbering / M. Crawford (20 min)
DNS mappings / C. Huitema (20 min)
IPv6 Name Lookups Through ICMP / M. Crawford (15 min)
Reverse Address lookup in DNS for IPng / O. Gudmundsson (15 min)
Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound (10 min)
Traceroute hop-by-hop option / A. Durand (10 min)
ECN Bit Assignment / S. Floyd (20 min)

Friday, December 12, 1997, 0900-1130, (Empire Room)

IGMP for IPv6 / S. Deering (15 min)
Neighbor Discovery over Tunnels / S. Deering (20 min)
IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta (10 min)
Site prefixes in Neighbor Discovery / E. Nordmark (20 min)
Router Alert / C. Partridge (10 min)
VRRP for IPv6 / R. Hinden (15 min)
DHCP vs. M & O Bits / Narten (10 min)
IPv6 Addresses in URL's / Deering, Carpenter (10 min)
Non-Corrosive Multi-Homing Idea / Matt Crawford

MONDAY, December 8, 1997, 1530-1730, (Empire Room)

Introduction / S. Deering
Review Agenda / S. Deering

Steve Deering introduced the meeting and reviewed the agenda.

UNH Testing Report / Bill Lenharth

Interoperability test session last week at UNH. First purely interoperability test session at UNH. First time to put routers into the test network. There were 10 hosts and 6 routers tested. 90% of the host implementations worked well as did 70% of router implementations. After work on site most of the problems discovered were "addressed". Both BGP4+ and RIPng routing protocols, including route redistribution, worked. Three long days of testing. Next test period is with Sun Connectathon in March. Both conformance and routing testing will be done. No IPSEC testing was done.

Document Status / R. Hinden

IETF Last Call completed for Proposed Standard

IETF Last Call completed for Experimental

IETF Last Call completed for Informational

Submitted to IESG for Proposed Standard

Submitted to IESG for Informational

Submitted to IESG for BCP

Status of moving base specs to Draft Standard / R. Hinden

BASE SPECS TO DRAFT

Will be sending questionnaire about implementation information to the ipngwg list in next day or two.

[Editors Note: Bill Lenharth of UNH, volunteered after to the session to help with this based on the testing being done at UNH. He will be contacting implementers.]

TLA/NLA Assignment Rules Status / R. Hinden

TLA/NLA ASSIGNMENT RULES STATUS

Met with registry folks this morning about their concerns about TLA doc. Progress made, but nothing concrete to report yet. Will report again at Friday session.

Resolve Neighbor Discovery and Addr Conf issues / T. Narten

Talk about remaining issues with ND and Addr conf doc.

Zero Lifetime denial of service attack

Not like other Denial of Service attacks

Proposal One

[pseudo code for algorithm]

This proposal limits removing prefix to 2 hours units. Can't remove one in shorter time.

Proposal Two [from Erik Nordmark]

Comments that this proposal, is just focused on TCP. Problem is worse, it affects all other transports, SNMP, etc. Everyone that the machine uses addresses. Attack is much worse than just TCP.

Suggestion that we should do both. They are not really in conflict. Could also use authenticated router advertisements.

Comment that this is not normal behavior for TCP. Should kill all state with TCP and other transports.

R. Hinden suggested that lifetimes less than two hours should be accepted only if packet was authenticated. This allows for finer grained control (e.g., less than two hours) in environments that need it and two hour everywhere else.

Suggestion was made for Proposal 1 unless packet was authenticated. If authenticated, then accept lifetime less than 2 hours. Strong consensus to adopt this proposal.

DHCP-specific bits in Router Advertisement

Proposal

Rational

J. Bound thinks we only need one bit. All that stateless is for is addresses and link parameters. A critical part of IPv6 is to make renumbering work. Important part of this is dynamic DNS. Thinks that the router should only control the address allocation. Rest of configuration is independent of what router can supply.

DHCP WG does not have a strong feeling either way.

Matt C. suggested that these bits tell the host when it is completely configured. If both bits are zero it is done. Otherwise it needs to go to DHCP to get additional information. It should not come up until it has all information.

Narten suggest wait to come to closure on this topic until after discussed by DHCP WG. IPng will continue this in the Friday session.

Default value for valid lifetime in Prefix information options:

Consensus to adopt this proposal.

Summary of Open Issues

[Editor's note: Remaining issue to be resolved at Thursday wg session before moving this to draft standard]

Mobile IPv6 Status / D. Johnson

High-level overview of operation:

Current spec is draft-ietf-mobileip-ipv6-04.txt

One implementation done so far (CMU). Other implementations in progress?

Editorial Changes:

Binding Update Option Changes:

Binding Update Option Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|C| Reserved | ID Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| (only present if C bit set) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Binding Acknowledgment Option Changes:

Binding Acknowledgment Option Format:
+-+-+-+-+-+-+-+-+
| Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Binding Request Option Changes:

Binding Request Option Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Home Address Option Changes:

Home Address Option Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Comments, please:

We need feedback/agreement from IPng Working Group. Please send e-mail comments to Mobile IP mailing list: mobile-ip@SmallWorks.COM

Comments can also be sent to: Dave Johnson, dbj@cs.cmu.edu

Wants processing of home address option on the receive side to be required by all receivers. Not just the ones that implement Mobile-IPv6. Need Home agents anycast address, and option code for bridging xxx, yyy, zzzz options.

IPng chairs will figure out how to do these allocations. Need to reserve a group of interface identifiers to be used as anycast addresses. Chairs promised to resolve issue this week.

Interface Identifier Global Flag / S. Deering

[Figure showing how EUI-64 based interface identifiers are created from IEEE 48bit MAC addresses]

Current algorithm for doing this fabrication inverts the state of the "Global/Local" bit. Becomes "1" if global, "0" if local.

Reason for inversion is to make it easier on links that do not have hardware tokens, such as dialup links, tunnels, etc. to set this bit correctly. Comment on mailing list that this is complex and the bit should not be inverted. IESG sent it back to the working group to review earlier decision.

Matt Crawford: Arguments in favor of inverting the bit. Makes it easier to recognize vendor type code when looking at wire. We are corrupting the use of EUI64 format. Would be better to not change bit.

KRE: Matt's comment is correct, but he came to the wrong conclusion. Packet trace will still have real MAC addresses at front of frame. Thinks a better way to do this would be to XOR with different value to make it look very different.

M. Wasserman: Thinks we should have a fixed prefix for manually assigned interface identifiers. Brian C: Thinks current approach will make things harder for maintenance technicians.

C. Huitema: Thinks the problem is reversed. Real problem is that managers will assign bit's incorrectly. Computers will not have a problem.

KRE: Also disagrees with Brian C. Thinks we should leave the way it is.

A. Durand: In the ten implementations he has seen nine out of ten do it correctly, and would like to keep it as it is.

S. Deering took poll. 1) Keep it as is, 2) eliminate inversion, 3) KRE proposal

Rough consensus to keep things the way they are now. Document editor will report wg consensus to area director. [Editor's note: done as of 12/29/97]

THURSDAY, December 11, 1997, 0900-1130, (Empire Room)

IPv6/NBMA Status / G. Armitage

ION wg summary relevant for IPng

Since last meeting

General Architecture

Major New Item / Shortcut suppression

Interpretation of Flow Label

Discussion regarding how this would interact with other usage of flow label. C. Huitema pointed out that it is backwards. Flow label indicates that it is a long-lived flow. That is the case when extra overhead to shortcut flow is worthwhile. No flow label probably indicates that flow will be short lived. Long discussion about merits/cons of this proposal.

draft-ietf-ion-ipv6-atm-00.txt

PVC rules

Document currently in ION working group last call. If doesn't go through quickly, ATM Point-to-Point link text will be moved to a separate document.

Status of "IPv6 Transmission over Frame Relay" and "Extensions to IPv6 Neighbor Discovery for Inverse Discovery" was also reviewed. They will become ION wg drafts and pursued there.

Router Renumbering / M. Crawford

RR Goals

RR Basics

RR Command Structure
[Using ABNF of RFC2234]

RR Result Structure

Lacking in current draft

Comments: Doesn't deal with result implosion. Author agrees, needs to be added. Is there any way to have routers tell what prefixes you have now without changing anything. Answer: could ask for zero prefix match and look at replies. Also use SNMP. Deering suggested to use similar mechanisms that IGMP uses to space out replies to multicast query.

Would like to see ICMP code assigned, then folks build implementations. Need to resolve open issues.

DNS mappings / C. Huitema

Revising the AAAA record

New AAAA Record?

Needs, let's take an example

+--------+ +--------+
| | | |
| TLA-1 | +--+ TLA-2 |
| | / | |
+---+----+ / +----+---+
| / |
| / |
+---+----+ / +----+---+
| +-+ | |
| ISP-A | | ISP-B |
| | | |
+----+---+ +---+----+
\ /
+--+--------------+--+
| Site |
+--------------------+
|
Host

What we have today will not scale

Using the new format solves the problem

Question 2 - Resource Record Number

Question 3 - Format compatibility

+---+--------+-------------+
| L | Suffix | Domain Name |
+---+--------+-------------+

+-----------------+---+-------------+
| 128 bit address | L | Domain Name |
+-----------------+---+-------------+

+-----------------+---+-------------+
| 128 bit address | 0 | ...... |
+-----------------+---+-------------+

A decision on AAAA record?

Question about impact on gethostbyname. Would not change gethostbyname interface in host. Could this be hidden from hosts? Answer: Doesn't work, caching problems, some parts short lived, some long lived. Won't work.

Authors conclusion is that we want to modify RFC1886. Recycle at PS.

How does this relate to dynamic updates?

Group wants to adopt this proposal. Then do a working group last call. This will replace RFC1886

IPv6 Name Lookups Through ICMP / M. Crawford

Who-Are-You?

Format

+-----------+-----------+-----------+-----------+
| Type | Code | Checksum |
+-----------+-----------+-----------+-----------+
| ID | unused |
+-----------------------+-----------------------+
| |
+ Nonce +
| |
+-----------------------------------------------+
| Time-to-Live |
+-----------+-----------------------------------+
| NameLen | |
+-----------+ +
| |
+ FQDN.... +
| |
+-----------------------------------------------+

Review of Motivation

Features

Status of -01

DNS Delegation and Renumbering

Two General Modifications to DNS

Problems

New Proposal

Non-Terminal CNAMEs

Counted Bit-Strings

+------+------------------+------------------------+
| 01xy | bit count | bit string |
+------+------------------+------------------------+

What they can do for IPv6

Discussion. Conclusions: Make ICMP approach experimental. With multiple names? With warnings for scope? Keep ICMP for link-local. Could also add local name to address lookups as well for dentist office operation.

Reverse Address lookup in DNS for IPng / O. Gudmundsson

IPng reverse DNS address lookup

DBIT (delegated BITs) record

DBIT Example

Example 1: Query for address

DBIT Example (2)

DNS Impact of DBIT records

Advantages of DBIT records


Discussion. Contrasted with other proposals. CH: Suggests leaving 1886 alone (existing practice), wait until the newer stuff is ready to bring forward when we have all of the tools. Suspect that 1886 and new ZNAME will be OK to pursue.

Chairs will discuss how to move these drafts forward and report back to the working group. J. Bound reports that this will slip deployment by six months.

Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound

RFC1233 Update

7. Agreement on change by hostbyaddr()

8. Suggest we use AI.Default as a system default. Also suggested to author off-line -> xxxxx

9. Name change suggestions:

Suggestion to use "node" instead of "host"

10. Add new AI_Flags to getaddrinfo() Warning - TOG/XNET owns this spec ????

Thanks to Bob, Sue, Jim, and Rich

[Jim Bound will send slides by email]

Traceroute hop-by-hop option / A. Durand

Round trip Traceroute

<draft-durand-ipv6-traceroute-00.txt>

Traceroute Problem

Proposed Solution

Traceroute hop-by-hop option

0 3
0 1
+-----------+-----------+
| Value=TBD | Length |
+-----------+-----------+-----------+-----------+
| ID | Ptr | Flags | Boundary |
+-----------+-----------+-----------+-----------+
| |
| space to record information |
.
.
.
| |
+-----------------------------------------------+

Router Information

0 3
0 1
+-----------+-----------+-----------+-----------+
| Type | HL | Medium | Reserved |
+-----------+-----------+-----------+-----------+
| MBZ | AS |
+-----------------------+-----------------------+
| |
| Address |
| |
| |
+-----------------------------------------------+

ICMP Traceroute message

0 3
0 1
+-----------+-----------+-----------+-----------+
| TBD | MBZ | Checksum |
+-----------+-----------+-----------+-----------+
| ID | HL | Medium | Reserved |
+-----------------------+-----------------------+
| MBZ | AS |
+-----------------------+-----------------------+
| Reserved |
+-----------------------------------------------+
| Address |
| |
| |
+-----------------------------------------------+

Strategy #1 Two Packet Traceroute

[figure of two packet traceroute]

Strategy #2 Limited Traceroute

[figure of limited traceroute]

Strategy #3 Debug Mode

[figure of debug traceroute]

Comments: Have looked at multicast route traceroute draft? Deering very nervous about debug mode because it generates so much traffic. Suggest modeling this like multicast traceroute and remove debug mode.

CH: Two problems with approach. Real reason IPv4 traceroute not uses was t hat it was a stupid idea. Debug mode is a great tool for denial of service attack. This is very bad.

M. Wasserman: Thinks proposal needs some more work. Likes the goal for what this does, but isn't sure this is the right mechanism.

Overall conclusion that work should continue.

DHCP vs. M & O Bits / Narten

M bit to control how if DHCP should be used to get addresses
O bit to get other info from DHCP.

Discussed in DHCP WG. Agreed on clarification to language in spec. Issue is if different advertisements have different M & O bit values also resolved. Once use DHCP keep using it. Ignore changes in bits. Text will also be clarified.

Bound suggested alternative. Bits not needed. If administrator has policy, then they control ND advertisements or turn on DHCP. Discussion and clarifications.

Comment bit is important, because otherwise you have to wait for a timeout before continuing.

Suggesting that we should keep bits and clarify usage. Bits are advisory. Hint to use DHCP or not.

Working group consensus to leave keep bits and clarify text as to usage.

FRIDAY, December 12, 1997, 0900-1130, (Empire Room)

Document Status (continues) / R. Hinden

Neighbor Discovery and Address Auto-Conf

Unicast Aggregation Formats draft

[Editor's note: Following additional discussions, author will change format to add a 8-bit reserved field between TLA and NLA field (reduces NLA to 24 bits). This resolves issue of allowing additional TLA's if routing system evolves to handle more top level routes but keeps initial limit at ~8K for initial allocations.]

TLA/NLA Assignment Rules draft

ECN Bit Assignment / S. Floyd

A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP

Internet Draft <draft-kksjf-ecn-00.txt>
ECN Web page: http://www-nrg.ee.lbl.gov/floyd/ecn.html

What is needed from IPv6

Where would the bits come from?

Planning an ECN BOF at next IETF. Could make a formal request to IESG for two bits in IPv4

Why two bits instead of one?

Why not Source Quench?

How would the router decide whether to drop the packet or set the ECN bit?

Does ECN make it easy for evil applications to ignore congestion control?

What applications would benefit from ECN

ECN Simulations and Experiments

IGMP for IPv6 / S. Deering

Based on IGMPv2 for IPv4 Spec (recently approved as proposed standard)

Changes of terminology from IPv4 version

Uses ICMPv6 message types, not protocol ID #2

Uses Link-local source address for messages

Didn't get new draft out prior to ID deadline. Will get it a week or two after IETF.

Packet Format

+--------+-------+-----------------|
| Type | Code | checksum |
+--------+-------+-----------------|
| Max resp delay | reserved |
+----------------+-----------------+
| |
| Multicast |
| |
| Address |
| |
+----------------------------------+

Types: Query 130
Report 131
Done 132

Code: 0

Max resp delay: in milliseconds

(Router alert also present)

Suggestion: Reserve these type codes in ICMP spec. Also the ND type codes. Also reference to other docs.

IPng Document editor will reissue ICMP draft with type codes.

Question about Multicast routing protocols: PIM and MOSPF currently support OSPF. DVMRP will not.

Neighbor Discovery over Tunnels / S. Deering

Should we run ND over tunnels and p-p links?

Suggestion that we need additional specification about how to run ND on point-to-point links. Bi-directional links only. Probably should not run it over uni-directional links. When a pair of routers are at ends of link, ND is also not needed. Routing protocols have needed functionality. In some ways ND is the routing protocol for Host-Host and Host-Router.

NUD may be used between routers. Required for other cases.

Should we consider ND on or off, or should we allow it's individual components to be used individually?

Questions:

Should we use ND between hosts and router on bi-directional p-p link? Deering would like this to be the case. Parts can be turned off as appropriate.

Issue may be mostly focused on address resolution.

Deering wants resolution of should we do this so, if so, we can write a document that defines operation.

Discussion.

Define p-p link as one that there can only be two nodes. Given that property, we can leave out specific ND components.

M. Wasserman will outline the issues on the mailing list.

IPv6 Transmission over IPv6/IPv4 Tunnels / A. Conta

<draft-conta-ipv6-trans-tunnel-00.txt>

Define

MTU

Tunnel Packet Format

Interface ID (token)

7 6 5 4 3 2 1 0 (bit order
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Random Number | MBZ |
+ +-----+-----+
. .
. .
. .
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+

Advantage: survives underlying physical interface NIC changes

Comment: This might conflict with vendor assignments. If using this, why transform the interface ID. Could use it without change.

Question are both end of links required to be on the same subnet. Answer: No we can have unnumbered links. Not prohibited either. Could also use link-local addresses.

Comment: It is very important to keep the token the same when rebooting, rebooting, etc.

Author will revise draft and republish.

Site prefixes in Neighbor Discovery / E. Nordmark

<draft-ietf-ipngwg-site-prefixes-01.txt>

Goals

Proposal

Open issue 1 - Mobile nodes moving off site and have been using site local addresses.

KRE: The problem is that we have not defined what is a site. Need to do this. Proposal: Node or link are never in more than one site. Some node/links are not in any site (used to connect sites).

Question about if tunnel is bi-directional or uni-directional. Issue is more complex.

Disagreement about KRE's definition of site. Alternative definition is that node can be in multiple sites and link can only be in one. Agreement on criteria that sites can never overlap.

Open Issue 2 - Node multihomed to multiple sites

+-------+-------------------+--------+--------------+
| xxxx | 0........0 | Subnet | Interface id |
+-------+-------------------+--------+--------------+
put random # here

Comment: Same issue as what we decided with link local addresses. Should not need random number. Just need to keep track of scope of these addresses. Additional discussion.....

Open Issue 3 - Site local address in DNS

Open Issue 4 - Include or remove global addresses?

Open Issue 5 - Encoding the exact semantics of advertisement:

Open Issue 6 - Security considerations:

Open Issue 7 - Assumes common SLA (subnet number):

Open Issue 8 - Are the benefits worth the added complexity?

Discussion will be continued on mailing list.

Router Alert / R. Hinden

This draft has been returned from the IESG for several changes. C. Partridge will be submitting a new draft in the next few weeks that should resolve the problems.

Comment: IPsec supposedly is requesting an additional code point in the router alert option for multicast key.

VRRP for IPv6 / R. Hinden

Virtual Router Redundancy Protocol (VRRP) developed initially for IPv4.

VRRP Overview

IETF

[Figure showing basic operation of VRRP]

VRRP Mechanisms

Additional Detail

Status

Issue for IPv6 is to either add VRRP features to neighbor discovery or to define a profile for current ND mechanisms that meet VRRP goals.

Comments were mostly to just use ND (with some tuning if necessary).

IPv6 Addresses in URL's / B. Carpenter

Design team meet in the bar a few nights ago.

Need numeric address in URL's for emergency operations (or robotic apps).

Colons break URL parsers "hostname" syntax

Proposals:

http://--ABCD-EF12-192.100.1.2.ipv6:80/
http://[ABCD:EF12:192.100.1.2]:80/

Issue: Should IPng wg. reopen the "colon" notation?

Heated discussion. Most comments that this is stupid, we should not reopen IPv6 text notation. Long discussion. Issue seems to be that many parsers that take URL's are very limited.

No one was in favor of changing current text representation. Extremely strong consensus!

It was noted that the issue is probably only relevant for complete web browsers (e.g., Netscape, Microsoft, etc.), not all other applications that use URL's. If the complete web browsers can be changed it is very likely to be sufficient. Recommend that the primary preferred syntax for IPv6 addresses in URL's be: http://[ABCD.EF01::2345:6789]:80/

The IPv6 address should be enclosed in brackets. URL parsers that can not support this notation can either support the proposed alternative syntax: http://--ABCD-EF12-192.100.1.2.ipv6:80/ or not allow IPv6 addresses to be entered directly.

Non-Corrosive Multi-Homing Idea / Matt Crawford

Goal

Three Magic Words

[three diagrams showing basic topology of site connected to two providers and how mechanism works when a link to one of the providers fails.]

Basic idea is for border router to send a renumbering message when link fails.

New flag for prefix info. option

Wants discussion on mailing list.

Slides

Johnson Presentation

Attendees List

go to list

Previous PageNext Page