2.3.7 IPNG (ipngwg)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 23-Jul-98

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

RFC1887

  

An Architecture for IPv6 Unicast Address Allocation

RFC1885

PS

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

RFC1897

E

IPv6 Testing Address Allocation

RFC1981

PS

Path MTU Discovery for IP version 6

RFC1888

E

OSI NSAPs and IPv6

RFC1972

PS

A Method for the Transmission of IPv6 Packets over Ethernet Networks

RFC1970

PS

Neighbor Discovery for IP Version 6 (IPv6)

RFC2019

PS

Transmission of IPv6 Packets Over FDDI

RFC2023

PS

IP Version 6 over PPP

RFC2133

  

Basic Socket Interface Extensions for IPv6

RFC2147

PS

TCP and UDP over IPv6 Jumbograms

RFC2292

  

Advanced Sockets API for IPv6

RFC2373

PS

IP Version 6 Addressing Architecture

RFC2374

PS

An IPv6 Aggregatable Global Unicast Address Format

RFC2375

  

IPv6 Multicast Address Assignments

Current Meeting Report

IPng Meeting Chicago IETF

August 25 & 27, 1998

Bob Hinden / Nokia, Co-Chair
Steve Deering / Cisco, Co-Chair

Minutes taken and edited by Bob Hinden

Introduction / S. Deering

S. Deering introduced the meeting.

Review Agenda / S. Deering

TUESDAY, August 25, 1998, 1545-1800

- Introduction / S. Deering (5 min)
- Review Agenda / S. Deering (5 min)
- UNH Interoperability Testing Report / W. Lenharth (5 min)
- Document Status / R. Hinden (10 min)
- New Documents to Draft Standard / R. Hinden (5 min)
- IPv6 Address Assignment Status / R. Hinden, R. Fink (10 min)
- IPv6 over NBMA & IPv6 over ATM Status / M. Jork (10 min)
- Mobile IPv6 Status / D. Johnson (10 min)
- Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering (15 min)
- IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung (30 min)
- DNS Extension to Support IP Version 6 / M. Crawford (30 min)
- PPP Extension for Prefix Allocation / K. Yamamoto

THURSDAY, August 27, 1998, 0900-1130

- Jumbograms / S. Deering (15 min)
- Maximum header length (or minimum assured payload length) / M. Ohta (15 min)
& Make PMTUD purely optional
- Router Renumbering / M. Crawford (15 min)
- Multicast Listener Discovery Protocol / S. Deering (10 min)
- IPv6 Naming interoperabilty issues / J. Paugh (15 min)
- Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews IP Address
- Allocation Ideas / Maarc Blanchet

UNH Interoperability Testing Report / W. Lenharth

Test period the week prior to the Chicago IETF meeting. There was a total of 19
participants from 10 companies/implementations. There were 3 that were just routers,
1 hosts only and 6 router / hosts.

Companies: Compac(DEC), Telebit(Denmark), Hitachi, WIDE, SUN, IBM, Masushita,
and Microsoft Research.

Tested Areas: Basic Spec, ND, MTU path discovery, BGP4+, RIPng and redirects.

Analysis of work:

We were unable to get all the routers to participate in a network configuration. Some
implementations could not run "nslookup ", to get up to date info from DNS.

IPv6: Some vendors have serious (halting) type v6 problems, others have solid
implementations. At this test period about 25% worked well.

Future Plans: The next test period will be at Connectathon99 in March of 1999. The
lab will continue to provide increasingly intense testing in a v6 network environment,
containing routing scenarios and network configurations using OSPF(v6) as well as
BGP4+ and RIPng.

Document Status / R. Hinden

RFC Published
- RFC 2373 IP Version 6 Addressing Architecture (PS)
- RFC 2374 An IPv6 Aggregatable Global Unicast Address Format (PS)
- RFC 2375 IPv6 Multicast Address Assignments (Info)

IESG Approved for Draft Standard
- IPv6 Specification
- ICMPv6
- Path MTU Discovery for IPv6
- Neighbor Discovery for IP Version 6 (IPv6)
- IPv6 Stateless Address Autoconfiguration

Deering reported that there will be a new version of the ICMPv6 draft to fix some
editorial oversights, before submission for publication as RFC.
IESG Approved for Proposed Standard
- MIB for IPv6: UDP
- MIB for IPv6: TCP

IESG Approved for Informational
- Proposed TLA and NLA Assignment Rules

IESG Approved for Experimental
- IPv6 Testing Address Allocation

IESG Previously Approved / Waiting for RFC publication
- MIB for IPv6: Textual Conventions & General Group (PS)
- MIB for IPv6: ICMPv6 Group (PS)
- IPv6 over PPP (PS)
- IPv6 Testing Address Allocation (Experimental)
- IPv6 Packets over Token Ring Networks (PS)
- Generic Packet Tunneling in IPv6 Specification (PS)
- IPv6 Packets over FDDI Networks (PS)
- IPv6 Packets over Ethernet Networks (PS)
- IETF Last Call completed for Proposed Standard
- IP Header Compression / Nov 97

Submitted to IESG for Proposed Standard
- IPv6 Router Alert Option
- IESG wants to reconcile w/ IPv4 Router Alert

IPng Working Group Last Call Completed for Proposed Standard
- Router Renumbering for IPv6

IPng Working Group Last Call Completed for Experimental
- IPv6 Name Lookups Through ICMP

Carpenter also noted the Business Case for IPv6 draft, originally a Bay Networks white
paper, most recently edited by Charlie Perkins, to eventually be published as an IAB
document. Solicits review from ipngwg. We will do a WG Last Call when Charlie
gives the go-ahead.

ACTION: Document editor will issue a w.g. last call when author give the go ahead.

New Documents to Draft Standard / R. Hinden
- Start Planning Next Set of Document for Draft Standard
- Possible Candidates:
- Addressing Architecture
- Aggregation Formats
- IPv6 over Ethernet, FDDI, TR, PPP
- Others?
- Next Step is to Collect Implementation Information

ACTION: Document editor will start process to advance Addressing Architecture,
Aggregation format, and IPv6over<LINK> to Draft Standard. Will also recommend
any other documents currently at Proposed Standard.

IPv6 Address Assignment Status / R. Hinden, R. Fink

Address Assignment Status
- "Proposed TLA/NLA Assignment Rules"
- Updated based on comments from LA IETF
- Presented Approach at RIPE Meeting in Stockholm
- Revised based on comments received at RIPE Meeting
- Revised based on email comments
- Submitted to IESG for "Informational" Status
- IESG Approved on 18 Aug 1998

Next Steps
- Plan is for TLA/NLA Assignment Rules to become New IANA Document
- First Requests made to Registries for Sub-TLA Assignments

Bob Fink reported that the following IPv6 sub-TLA requests have been made:
- uunet-uk to RIPE-NCC
- Esnet to ARIN
- WIDE to APNIC

- Primary intent of these initial requests is to assist registries in setting up their
process and in interpreting the TLA/NLA rules.

- We are NOT trying to start an Sub-TLA "Land Rush".

- If you NEED an IPv6 Sub-TLA AND are familiar with the "Rules" RFC, please
proceed, otherwise wait.

IPv6 over NBMA & IPv6 over ATM Status / M. Jork

ION WG Last call ended
- draft-ietf-ion-ipv6-01.txt
- draft-ietf-ion-atm-02.txt
- draft-ietf-ion-fr-00.txt
- draft-ietf-ion-ind-00.txt

Issues around IPv6 over ATM in PVC mode raised by the WIDE project have been
resolved one week after the last IETF.

New ND option number in <draft-ietf-ion-ipv6-01.txt> needs official blessing.

Document editor reported that he has put together "tentative" assignments for this and
other pending requests (e.g., IPv6 options, ICMPv6 types, etc.). These have been sent
to the IANA. Expects them to be approved in a few weeks.

ACTION: Put the "tentative" assignments on the IPng web site until the IANA
publish them.

Mobile IPv6 Status / D. Johnson

Changes in the latest Mobile IPv6 Draft <draft-ietf-mobileip-ipv6-06.txt>

Completed Mobile IP w.g. last call.

Minor Changes and Corrections
- Advertisement Interval option MAY be included by any router, not just by home agents
- Any router MAY use relaxed limits on MaxRtrAdvInterval and MinRtrAdvInterval
to allow faster Advertisements
- Documented new limits on MAX RTR SOLICITATIONS and RTR
SOLICITATION INTERVAL for mobile nodes sending Router Solicitations
while away from home
- If a mobile node has multiple home addresses using different interface identifiers,
it SHOULD send a separate Binding Update to its home agent for each
- Finally filled in Section 2, giving a comparison of Mobile IPv6 with Mobile IP for IPv4

Modified Prefix Information Option Format On Router Advertisement:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

New flag bit Router Address (R):
- Set to indicate whole Prefix field is router's address
- Compatible with existing uses of Prefix field
- Router MUST include in solicited Router Advertisement
- Router SHOULD include in unsolicited Router Advertisements

New Home Agent Information Option Format
- On Router Advertisement:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

- Allows home agent to advertise values about itself:
- Preference: Signed value (default 0) used for sorting reply list for dynamic
home agent address
- discovery
- Lifetime: Can give lifetime separately from router lifetime
- Use in dynamic home agent address discovery:
- Home agents remember values in Home Agents List
- In discovery reply, home agent includes self in list only if not highest preference

Receiving Packets While Away From Home
- IPv6 suggests that nodes MAY reverse received Routing header for response packets
(if authenticated)
- But for mobile node away from home this is bad:
- Routing header directs packet to care-of address then to home address
- Reversing Routing header would send response out looped back through

- Inefficient, and confusing to receiving node
- For response packets by mobile node away from home:
- SHOULD NOT include care-of address as first hop in route
- If no other hops, SHOULD NOT include Routing header

Address Scope Issues
- Packets addressed to a mobile node's site-local address:
- Consensus is SHOULD be forwarded while away from home
- But this behavior MUST be configurable to disable it
- This default might change as ``sites'' and site-local addresses become better defined
- Multicast packets with link-local < scope < global:
- Same as site-local unicast above
- This default may change as multicast scopes become better defined

Binding Lifetime Rules
- New rules specified to limit lifetimes:
- On primary care-of address registration:
- Home agent MUST reduce lifetime to no greater than remaining prefix lifetime
- When sending a Binding Update:
- Mobile node MUST NOT send lifetime greater than remaining binding lifetime
for home registration
- Ensures no use of binding beyond home address lifetime

Renumbering the Home Network
- Home agent watches for ``important'' Router Advertisements:
- The preferred or valid lifetime for an existing prefix on the home link is reduced
- A new prefix is introduced on the home link
- State of home agent's AdvManagedFlag flag changes
- When any of these occur:
- Home agent tunnels constructed Router Advertisement with changed info and

- to mobile node
- Retransmits until Binding Request is answered
- Ensures important Router Advertisement changes seen by mobile node

Question about implementation experience. Currently CMU (adding current IPSEC
(FreeBSD), Lancaster university (Linux), National Univ. of Singapore (Linux).

Reserved IPv6 Subnet Anycast Addresses / D. Johnson, S. Deering
<draft-ietf-ipngwg-resv-anycast-00.txt>

Which part of Address Space to Reserve?

- Many official and unofficial Uses of low-numbered interface ID's
- End os a point-point link
- Tunnel endpoints
- Manually configured unicast addresses when a hardware token is not available

- Manually configured static addresses for each of the routers on a link.
- Not possible in practice to "reserve" them for a new use (anycast). Thus reserve

Reserved Subnet Anycast Addresses

- Reserve highest 128 interface ID values for subnet anycast
- Reserved subnetanycast addresses format:

n bits 121-n 7 bits
+-----------------------------+-----------+------------+
| subnet prefix |1111...1111| anycast ID |
+-----------------------------+-----------+------------+
| Interface ID field |

- The anycast ID identifies a particular reserved anycast addresses within the
subnet prefix:

Decimal Hex Description
---------- ------ --------------

127 7F Reserved
126 7E Mobile IPv6 Home-Agents anycast
0-125 00-7D Reserved

- Reserved in EVERY prefix on ALL links.

How Many Addresses to Reserve
- Minimum size of interface ID is currently undefined in IPv6
- We don't want to change that with this draft
- But minimum size of interface ID must be bigger than reserved part of space:
- Some part if interface ID space is for anycast
- Rest of space allows some unicast addresses
- Reserving 128 addresses allow 1-byte interface ID's
- Careful management retains additional flexibility:
- Assign new anycast IDs in descending numerical order
- Can reduce number of reserved IDs if not all assigned yet
- Can increase number of reserved IDs if can be sure not in use for unicast (or

Discussion:

Is 127 the correct size? Suggestions?

Deering added that the issue was what is min size of interface ID. Do we think that
we may have Interface ID's that are smaller than 64 bits.

Nordmark: Could we move boundary to get more if we need them.

Discussion about how many to have. Not strong opinion to change size. Size will be
kept 127.

Problem w/ bit flip, will be fixed in new version of draft.

ACTION: Document editor will issue a w.g. last call after new draft is out.

IPv6 over IPv4 w/out Explicit Tunnels / B. Carpenter, C. Jung

Work started out in IPng, moved to NGTRANS because was related to transition, but
now back here because is another cast of IPover<Foo> document. Needs to be
standardized in IPng w.g.
- Uses IPv4 multicast (on site) as virtual multicast LAN.
- No changes of IPv6 model
- Just another IPv6over<Foo>

Two implementations currently
- Microsoft Research on NT
- UCLA on FreeBSD

Any issues? Advance to Proposed Standard?

Question and discussion about default MTU size.

Suggestion to reduce to 1460 to allow tunneling / options / etc.
Discussion. Decision to leave as is.

ACTION: Document editor will issue a w.g. last call after new draft is out.

DNS Extension to Support IP Version 6 / M. Crawford

Status of -ipngwg-dns-lookups-01
- Merges dns-lookups-00 and aaaa-03.
- Modified AAAA RDATA format, discussed to death in L.A.
- 128 bits + prefix length + prefix DNS name
- Address space delegations rely on new DNS features
- Binary labels
- Longest match lookups no longer needed
- DNAME RR
- Ready for W.G. last call

MUSTs and SHOULDs
- AAAA prefix name MUST NOT indicate a AAAA w/ a longer prefix.
(Equal is OK).
- No good way to signal an error, so offending record MUST be ignored;

- Suggest zone maintainers run a check.
- Address delegations SHOULD all be through DNAME, never NS.
- SUGGEST using the tag "ipv6" uniformly in the reverse zones.

Examples

X.EXAMPLE is dual-homed to A & B; A is dual-homed to C & D.

$ORIGIN X.EXAMPLE
wwww AAAA ::1234::567:9ABC:DEF0 64 subnet-1.ip6
subnet-1.ip6 AAAA 0:0:0:1:: 48 ip6
ip6 AAAA 0::0 48 subscriber-x.ip6.A.NET.
AAAA 0::0 48 subscriber-x.ip6.B.NET.
\[x0001/16].ip6 DNAME subnet-1.ip6
\[x123456789ABCDEF0].subnet-1.ip6 PTR www

$ORIGIN ip6. A.NET
subscriber-x AAAA 0:0:0011:: 40 A.NET.ip6.C.NET.

\[x11/8] DNAME ip6.X.EXAMPLE.

Usage/Deployment Notes
- Higher and lower network entities (e.g., provider and site) must agree on a name
like "subscriber-x" to hold the delegated prefix bits, or ...
- Binary label corresponding to the delegated bits themselves could be used for that
- Then the lower zone would have to be touched when renumbered, but

No issues raised.

Question about phase in v.s. flash cut over. When will this DNS code be available.
6BONE issue?

ACTION: Document editor will issue a w.g. last call when new draft is out.

PPP Extension for Prefix Allocation / Kazu Yamamoto

IPv6CP extension for prefix allocation

+--------+--------+
| IPv4 | IPv6 |
+--------+--------+
| IPCP | IPV6CP|
+--------+--------+
| LCP |
+-----------------+

- IPCP can allocate only one IPv4 address
- In IPv6 environment, we want more!
- Prefix allocation is necessary
- New IPV6CP option for prefix allocation

Question about could ND be used to do this instead? Could use this to report prefixes?
Wasn't sure. Might be a possibility.

IPV6CP Prefix Options

- Common format for Request and ACK

+-------+-------+-------+---------+
| Type | Lengt | Res. | Entry # |
+-------+-------+-------+---------+
| Reserved | Pref Len |
+-----------------------+---------+
| Valid Lifetime | \
+---------------------------------+ |
| Preferred Lifetime | |
+---------------------------------+ | Entry
| IPv6 Prefix 0-3 | |
+---------------------------------+ |
| IPv6 Prefix 4-7 | /
+---------------------------------+
| next entry |
| |

Discussion.

Question asked is prefix permanent or does it go away when the PPP connection is
down? Or how is prefix refreshed when lifetime expires? Would like prefix to
be permanent.

If approved for PPP, we should also do this for DHCP (e.g., allocation prefix). Maybe
not a good idea.

Point made that Router Renumbering could be used for this as well. Not good to have
multiple ways to do the same thing. Better to use current mechanism.

Needs further discussion.

THURSDAY, August 27, 1998, 0900-1130

Jumbograms / S. Deering

When IESG advanced base IPv6 spec from Proposed Standard to Draft Standard, one
issue the IESG had was that there wasn't enough implementation experience w/ the
Jumbogram option. The option was removed from the base spec and published as a
new internet draft.

Deering added some text to describe some error cases that were not handled in the
original text. Encourages people to do more real testing w/ this option.

The chairs plan is to submit the new draft for Proposed Standard and to request Draft
Standard status once interoperability has been demonstrated.

Report from Kevin Lahey (NASA Ames) that they have it running on NetBSD and
would like to do testing w/ other implementations. They could also host testing w/
other implementations.

Maximum header length (or minimum assured payload length) & Make PMTUD
purely optional / M. Ohta (15 min)

Limit Maximum Header Lengths

The Header Length Problem
- Header Length + Playload length <= Reconstruction Buffer Size (1500 or...)
- Fragmentation does not help
- TCP does not work if headers before the TCP header >= 1480
- DNS assumes minimally assured Payload length of 512 (though with a wrong
estimate of UDP header
- length)
- Not all headers are under application control

Proposal
- Allow Transport Protocols assure minimum payload length (after transport header)
of 1024 by making transport header length <= 64)
- Limit Maximum Header Length before Transport Header 192 (or 412) (unless
PMTU is larger than 1500? But your PMTU may vary dynamically...)

Make PMTU Discovery Optional

Why Large MTU
- Larger MTU means less header and packet processing overhead
- You may want to have a LAN with huge MTU (even though RTT is small and
CRC-error prone)
- PMTU will almost always be between 1280 and 1500

PMTUD not Useful
- PMTUD had limited usefulness when minimum MTU was 576
- PMTUD not applicable for one time connectionless communication
- PMTUD not applicable for multicast (hosts will be efficient enough to be able to
decode multicasted video with MTU of 1280)

PMTUD is BAD because
- Extra burden on Routers by retry
- No specification on retry interval

Proposal
- Make PMTUD purely optional
- Host should always assume PMTUD of 1280

Discussion on Limit Maximum Header Lengths:

Deering: On first topic, after discussion on mailing list, doesn't think problem being
handled is a real problem. Applications will not create extremely large headers. It is
a theorical problem. As soon as a budget is imposed on max header size, then one is
forced to create limits for every header type. Doesn't think this will work. In most
cases every header will be less than the maximum length. Example of UDP of w/
IPv4 shows the problem could theoretically happen, but in practice does not. Would
also limit headers in control packets where there there is not an issue w/ transport
payload size.

Nordmark: With IPSEC in IPv4, there does not appear to be a problem today. No
limit on IPSEC headers. Thinks it is very limiting to limit size. In the future link
MTU's may be different. We should not constrain the flexibility now without a
strong reason. It is very hard to predict what the future will be in 20 years. We
should make it flexible.

Comment that we should not put arbitrary limits on header size.

Discussion on Make PMTU Discovery Optional:

Kazu: Dislikes problems because TCP exchanges MSS, TCP can find appropriate
MTU by itself. Doesn't like this limitation.

Deering: If there is not a retry interval, there should be. It should be around 10
minutes. This is not a great load on routers. Not significant. Someone reported that
the retry interval in current RFC is 10 minutes.

More general issue is that eliminating the PMTUD creates an "internet cell size" for
all time. We should not limit this. We might want bigger MTU's later. What we
have now is a wonderful scheme that has zero cost and will allow us to adapt to
future changes.

Comment that just because applications work well w/ 1280 or less now, doesn't mean
that they will do so in the future. We should not limit what we can do in the future.

Deering polled the room on each proposal. Strong consensus to not adopt proposed changes.

Router Renumbering / M. Crawford

Issues addressed by -04 draft
- Various working changes and typos
- Gathering more definitions together
- Random delay in responses.
- Multicast target limited to an All-Routers address of site- or link-scope.
- This eliminates an obscure error condition.
- List address formats forbidden to create, define error flag if one is attempted.
- InterfaceIndex in result message now comes from IPv6 MIB.
- Clarify ICMPv6 checks
- Define changes of prefix to same value so that is is never unconfigured
- List ND parameters affected by RR.

Not addressed by -04 , in -05 alpha
- MinLen, MaxLen bounding lengths of prefixes to be tested
- Add explicit bounds checking for certain fields, and an error flag if checks flag.
- State that implementation algorithm may vary as longs as results are the same.

Not address by -04, in -05 beta
- Limit of random response delay should be msec, not seconds
- Use purely IPSEC, no custom authentication
- Added a new message type to support this: Sequence Number Reset
- Meaning: Invalidate all keys used for RR, reset Recorded Sequence

Questions about network partitions. Answer is that Reset is "idempotent" and can be
retransmitted.

Kazu: How could site ask request to be renumbered. Answer: no request reply, but
provider could retransmit advertisement.

Deering: How can this be used for initial prefix assignments?

Discussion about how this could be used for initial router configuration.

Comment to add clarification that routers should save this new info in non-volatile
storage.

ACTION: Document editor will forward to IESG for PS. W.G. last call was
completed prior to previous IETF meeting.
Multicast Listener Discovery Protocol / S. Deering

Received comments on clarification of text. Believes there are several implementations.

Deering explained that MLD for IPv6 is based on IGMP version 2 for IPv4. Version
3 of IGMP currently being designed, and a new working group will probably be
formed to shepherd that work through the Standards process. We would expect a
corresponding new version of MLD to also be an output of that work. The new version
of IGMP/MLD adds the capability to specify a "source filter" when joining a multicast
group, so as to request reception of multicast from ONLY a specified set of sources, or
from ALL BUT a specified set of sources. The new version will be backwards
compatible with the current version, that is, in the presence of current version
implementations the new version will revert to current behavior.

Comment that MLD requires Router Alert. Need to make sure that Router Alert
moves forward.

ACTION: Document editor will issue a w.g. last call when new draft is published.

IPv6 Naming interoperabilty issues / J. Paugh

Current Proposal for Storing IP Addresses
- IPv4 and IPv6 addresses stored separately
- NIS map, NIS+ table and /etc file created for IPv6 addresses
- Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses
- Separate IPv6 database can be served by older slave/replica

New IPv6 Database Created
- nodes.byname/nodes.byaddr maps for NIS
- nodes.org_dir table for NIS+
- AAAA record for DNS
- /etc/nodes file for local file
- Updated utilities to create nodes database
- ypmake(1M), nisaddent(1M), nispopulate(1M), etc.

[slide w/ graphic]

Issues W/ Current Proposal
- Stuck w/two "hosts" files, for ever
- No provision for deprecating "hosts" database (/etc/hosts, hosts.byname, etc.)
- Nuisance administration long after transition period
- AI_ALL lookups requires two call s to name services
- Is it possible to put IPv4 and IPv6 addresses in one place and still preserve
backward compatibility with legacy applications?

An Alternative Approach
- IPv4 and IPv6 addresses stored together /etc/nodes
- /etc/hosts preserved for legacy applications
- IPv6 applications will use /etc/nodes for v4 and v6 addresses. IPv4 lookup will
fail over to /etc/hosts
- Legacy applications lookup will continue to use /etc/hosts.
Long Term Benefits
- One database, one lookup for IPv4 and IPv6 addresses
- /etc/hosts can be deprecated, leaving one database for IP addresses
- Simplified administration of one database

Risks
- During transition, two locations for IPv4 addresses creates synchronization issue
- Requires comprehensive update policies and administration model during transition
- Lookups for IPv6 hosts with no IPv4 interface will always fail over to hosts,
requiring two lookups (will require code change when "hosts"is removed).

Comments: Given failover, could put all IPv4 in /etc/hosts, and later add them to
database w/ IPv6 addresses.

Should <...-bsd-frag-00.txt> added to Advanced API / M. Andrews

Draft designed to tell kernel that it needs to always fragment and not do path MTU
discovery. Only comments were based on security.

Wants to know if should add this to Advanced API document.

Discussion. Consensus to fold this into revision of Advance API draft.

IP Address Allocation Ideas / Maarc Blanchet
<draft-blancet-ipaddressalloc-00.txt>

IPv4
- RFC1219 on the assignment of subnet numbers
- Able to delay your decision for the final subnet mask of your net without
renumbering.
- Use leftmost bits for network numbers
- Use rightmost bits for host numbers

IPv4 Example

+------------------------+--------+--------+
| | | |
+------------------------+--------+--------+
<--->
100 001
010 010

001 100
101 101
011 110
111 111

IPv6
- Prefixes
- Many allocation boundaries (TLA, subTLA, NLA, XLA, YLA, SLA, DLA,
department,...)...)
- Draft proposes a generalization of RFC-1219
- Use left bits for the TLA allocation prefixes
- Use rightmost bits for the LLA (last level aggregator)
- Use <<centermost>> bits for all others

IPv6 Example

+--------+--------+--------+------------+--------+--------+
| | | | | | |
+--------+--------+--------+------------+--------+--------+
| <-|-> <-|-> <-|-> |

100 001000 001
010 000100 010
110 001000 011
001 001100 100
101 010000 101
011 010100 110
111 011000 111
011100
000010

Considerations
- This is not a new allocation scheme for IPv6
- It is there to help any organization that is allocating addresses (at any level: ex.:
SLA to departments)
- Informational

Discussion:

Deering thinks that a document discussing this would be valuable. Not everyone
knows these "tricks". Nordmark thinks it makes sense to provide the correct allocations
for IPv6.

Document should be "Informational". Not a Standard track or BCP.

Important to change title to be clearer that this document is an IPv6 address
assignment plan.

ACTION: Document editor will issue w.g. last call when new draft is out.

AAAA Record Code Point / Matt Crawford

Current RFC
- Complete IPv6 Address (16)

Draft
- Address "suffix" (16)
- Prefix length (1)
- Prefix DNS Name (var)

Alternate (New RR Type)
- Prefix length (1)
- Address "suffix" (1-16)
- Prefix DNS Name (var)

Augments for a new RR type
- Avoid complaints of a wrong RDATA length
- Can add a "Type A additional section processing" rule to the new type.
- Save a few bytes in DNS replies
- Estimate ~50 bytes in a "typical" NS or MX reply

Arguments against ????

Discussion:

Would new type require resolver to make additional requests? New resolver would
not get new record. When could new resolver code be available? Adding a new
type would probably make transition easier. Bounds thinks new type code is a good
idea. It might take a year to deploy change, but..

Strong consensus for new type code.

Comment that record name also needs to change. Suggestion for "A6".

Consensus to remove unneeded initial bytes.

ACTION: Document editor will issue w.g. last call when new draft is published.

Prefix Allocation / Kazu Yamamoto

Model of Prefix Allocation

+----------------+
| |
| ISP |
| |
+-------+--------+
|
+-+
| |
+-+
|
|
| <----- prefix allocation
|
|
+-+
| |
+-+
|
+-------+--------+
| | <------ Renumbering
| Site | aka
| | prefix distribution
+----------------+

Prefix Allocation
- Interaction w/ ISP
- Request and Response
- Shared key w/ ISP
- Over tunnel?

Prefix distribution
- Within Site
- Command and Report
- Secret key within site

Requirements for prefix allocation
- Request and response
- Key separation
- Server discovery

Discussion:

Deering thinks that site prefix allocation being temporary is not correct model. More
sites will be moving to permanent allocations.

Comment autoconfiguration is very important. Doesn't like using PPP for this, but
would like to see routers autoconfigure. Protocol mechanisms is useful for cable
modems, xDSL modems/routers, etc. Likes models for appropriate for many situations.

Some customers will not want it to be automatic, but there are scenarios that this will
useful. Note made that DHCPv6 might be able to be extended to handle this service.

Bringing up a new link is an implied "request". Link coming up could cause RR
message to be sent.

Maybe a new w.g. could be formed to handle this and related issues. Could be very
broad. Important issue. Not sure proposed mechanisms are adequate. Distinction
between mechanisms that require centralized administration and those that do not.

This is an important issue. We should continue discussion on the mailing list. This
is very good start. Well put on agenda for the next meeting.

Charlie Perkins asked for comments on "case for IPv6" draft. Please send him
comments at <cperkins@eng.sun.com>. This is an IAB document. Draft is:
<draft-ietf-iab-case-for-ipv6-02.txt

A IPng w.g. last call will be issued when the next version is published.

Meeting Adjourned

Slides

Changes in the Latest Mobile IPv6 Draft
Agenda

Attendees List

go to list