Editor's note: These minutes have not been edited.
IPng Working Group Meeting
December 1996 IETF
San Jose, CA
Robert Hinden / Ipsilon Networks
Steve Deering / Cisco Systems
Co-Chairs
Minutes taken by Robert Hinden
--------------------------------------------------------------------
Agenda
--------------------------------------------------------------------
Monday 1:00-3:00pm
Introduction and Bash Agenda / Steve Deering (5 min)
Document Status / Bob Hinden (10 min)
ITU Addressing Request Status / Bob Hinden (1 min)
Priority Field / Steve Deering (10 min)
Default Hop Limit / Steve Deering (10 min)
IPv6 over Token Ring (10 min)
BSD API / Bob Gilligan (10 min)
Simple IPsec API / Dan McDonald (5 min)
Advanced API spec / Matt Thomas (15 min)
Tunneling Spec / Alex Conta (10 min)
Header Compression spec / Micke Degermark (10 min)
Host Anycast / Jim Bound (10 min)
IPv6 Multicast Address Assignment draft / Bob Hinden (5 min)
Monday 7:30-10:00pm
8+8 Addressing Proposal / Mike O'Dell (45 min)
Alternative Addressing Architectures / Masataka Ohta (5 min)
Multihoming / Source Address Selection / Steve Deering (30 min)
Interface ID Proposal / Steve Deering (20 min)
IPv6 MIB / Dimitry Haskin (15 min)
Thursday 1:00-3:00pm
IPSEC
Report on UNH Interoperability Event
8+8 Proposal
Router Alert Option / Ran Atkinson (10 min)
Moving Base IPv6 Specs to Draft Standard / Steve Deering (30 min)
IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter (15 min)
Multicast Routing / Thomas Narten (10 min)
Router and Network Renumbering / Geert Jan De Groot & Bob Hinden
Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden (10 min)
Address Prefix Notation / Alain Durand (5 min)
Unspecified Address in Neighbor Discovery (5 min)
------------------------------------------------------------------
Introduction and Bash Agenda / Steve Deering
------------------------------------------------------------------
Steve Deering introduced the meeting. He said he now works for the
"borg" (e.g., Cisco systems). He introduced Bob Hinden from Ipsilon
Networks (who said had not been assimilated (yet)). Summarized sessions
and 6bone BOF.
Reviewed agenda. Asked for additional or removal of agenda items.
Question was raised about discussing TAG switching use of IPv6 flow
label. Deering said depends on outcome of Tag switching BOF.
Short report on a new implementation of IPv6 for Linux, done at INRIA,
and to be available for research use. It was announced by Jean Bolot.
Further info can be found at http://www.inria.fr/rodeo/IPv6/
------------------------------------------------
Document Status / Bob Hinden
------------------------------------------------
The following RFC's were published with Proposed Standard status:
- RFC1970, Neighbor Discovery for IP Version 6 (IPv6)
- RFC1971, IPv6 Stateless Address Autoconfiguration
- RFC1981, Path MTU Discovery for IP version 6
- RFC2019, A Method for the Transmission of IPv6 Packets over FDDI
Networks
- RFC2023, IP Version 6 over PPP
The following RFC's were published with Experimental status:
- RFC1888, OSI NSAPs and IPv6
The following document was advanced to Proposed Standard by the IESG (but
has not been published as an RFC yet):
- An IPv6 Provider-Based Unicast Address Format
------------------------------------------------
ITU Addressing Request Status / Bob Hinden
------------------------------------------------
Hinden reported that he had not done this yet, but would do it prior to
the Thursday IPng session. He did complete this by the Thursday
session. The reply is included here.
Internet Engineering Task Force
IP Next Generation Working Group
December 11, 1996
Mr. H. V. Bartine
AT&T Bell Labs, Room 4K-316
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
Subject: Response to ITU SG 7 Request for IPv6 Addressing Code Point
The IETF received a request from ITU-Telecommunication Standardization
Sector STUDY GROUP 17, Rapporteur Q3/7 on 17 July 1995. The ITU
requested an IPv6 Format Prefix for X.121 Public Data Network Addresses.
It also suggested that ITU-T Study Group 2 may also make a similar
request for E.164 addresses.
The IP Next Generation working group of the IETF discussed the request at
the working group meeting held on June 24, 1996 in Montreal.
The working group concluded that X.121 Public Network addresses are not
Internetwork addresses and that a Format Prefix (code point) was not
warranted at this time. Consequentially the working group concluded that
a better approach would be to treat the X.121 addresses in a manner
similar to how IPv6 runs other networks technologies such as Ethernet,
FDDI, Token Ring, etc. A definition of interface identifiers from the
X.121 addresses should be created. The BCD digits of the X.121 address
would be converted to binary and used as an Interface Identifier. An
IPv6 over X.121 Public Data Networks document could be written in a
manner similar to RFC1972 "A Method for the Transmission of IPv6 Packets
over Ethernet Networks" or RFC-2019 "Transmission of IPv6 Packets Over
FDDI". This approach would be compatible with the IPv6 control functions
as defined in RFC-1970 "Neighbor Discovery for IP Version 6 (IPv6)". It
would also support the creation of small independent subnetworks (e.g.,
clouds) in the X.121 Public Data Networks instead a single very large
subnetwork.
At the working group meeting an alternative approach was also suggested
that would make use of the AFI for X.121 addresses in the NSAP addressing
plan. This would fit into the framework defined in RFC-1888 "OSI NSAPs
and IPv6". This alternative provides another approach to support running
IPv6 over public networks that use X.121 addressing.
The IPng working group would also like to invite representatives from
ITU-T SG7 to attend the next IETF meeting and to present the IP Next
Generation working group their thoughts on how IPv6 could be run over the
public data networks.
We look forward to your response in this manner.
Contact Person:
Robert M. Hinden
Ipsilon Networks, Inc.
232 Java Drive
Sunnyvale, CA 94089
TEL: +1 408 990-2004
email: hinden@ipsilon.com
------------------------------------------------
Priority Field / Steve Deering
------------------------------------------------
Deering proposed at the Montreal meeting to change the definition of the
priority field and make it reserved. The original intent was to:
- Generalized "drop-preference" provides the wrong incentive,
encourages sending packet that won't be delivered
- Potential other uses for those bits (e.g., "RED" bit, Clark's
in/out-of-profile bit, ISP-private use.
This proposal was disliked by people who want to favor interactive
traffic over dialup or wireless links.
Steve Deering proposed a new definition:
- Declare that 4 bits of Priority are rewritable 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.
o Delay more important than throughput
o Suggests that routers/ISPs use other bits before touching the
"interactive bit".
o Affects queuing only, not routing (since re-writable).
Deering will write up as a email message and send to list.
------------------------------------------------
Default Hop Limit / Steve Deering
------------------------------------------------
At last meeting we discussed a proposal to make default hop limit to 255.
Discussion on mailing list came to conclusion that 64 would be better
choice. Deering proposed that we make this the default value. Working
group agreed to 64. Note: This has no effect on the use of setting the
hop limit to 255 as a mechanism to insure that the packet has not gone
off link.
Document editor will send email to IANA to add this parameter to IANA
registry for IPv6 defaults.
Christian Huitema suggested that routers should not advertise any default
hop limit value without being explicitly configured. Discussion. There
was not a consensus reached on this topic. Will be discussed further on
the email list.
------------------------------------------------
IPv6 over Token Ring / Bob Hinden
------------------------------------------------
Bob Hinden discussed remaining issues with "IPv6 over Token Ring" draft.
The main issues are how to handle mixed media bridging and token ring
source routing.
Conclusion was to add section describing how to handle mixed media
bridging. Main issue is the selection of MTU. Default (without any
configuration) should be 1500.
There may not be perfect solutions but it important to document issue so
device can be configured correctly.
Does token ring source route takes up space in packet, so MTU becomes
smaller.
Thomas Narten offered to own getting these issues resolved and getting a
new version of the draft. A working group last call will be done when
this ID is out.
------------------------------------------------
BSD API / Bob Gilligan
------------------------------------------------
Rich Stevens is now co-author. Split advanced features to a separate
document. Changes from previous version include:
- Added section on interface identification (in sync w/ Advanced API
spec).
- Change multicast setsockopt() options to use interface
identifiers. Previously used IPv6 addresses which do not work in
all cases.
- Added descriptions of gethostbyname(), gethostbyname2(), and resolver
options. This matches the new version of bind (4.9.4).
- Posix-free description of getaddrinfo() to match Posix 1003.1g (but
Posix is definitive spec)
- Added description of getnameinfo(). This is inverse function to
getaddrinfo(), not in Posix 1003.1ga
- Renamed inet6_isipv4addr() to inet6_isipv4mapped() to make name more
clearly describe function.
- Small working clarifications.
Gilligan commented that change the priority field definition would
require this specification to change too.
Document editor will do a working group last call on this document. Goal
is to publish an informational RFC.
------------------------------------------------
Simple IPsec API / Dan McDonald
------------------------------------------------
IPsec is mandatory to implement in IPv6. Reviewed basic concepts of
IPsec functions and terminology. Summarized API functions:
- All socket options are at the IPPROTO_IP or IPPROT_IPV6 level.
- Categories are the actual options to be set are IP{,V6}_AUTH_LEVEL,
IP{,V6}_ESP_TRANS_LEVEL, and IP{,V6}_ESP_NETWORK_LEVEL
- Levels are the values for IPSEC_LEVEL_NONE, IPSEC_LEVEL_AVAL,
IPSEC_LEVEL_USE, IPSEC_LEVEL_REQUIRE, IPSEC_LEVEL_UNNIQUE
- Need one additional level for special apps.
Change terminology to call it "payload" instead of "transport" because
it may not always be a transport protocol.
This work is being done in IPsec group and will be advanced there.
------------------------------------------------
Advanced API spec / Matt Thomas
------------------------------------------------
Check if w.g. is happy with advanced API spec.
Matt poised several questions to the working group:
- Scope. Would be nice to extend definition of scope to extend.
- Does WINSOC copy this work? Not too much. This follows POSIX,
WINSOC does not.
- Neither API doc has any mechanism to set the "flow id". Think it
belongs in this API doc or one of the other API documents. Deering
thought this would be correct place to put it. There needs to be a
kernel function to pick flow labels inorder to make they don't
collide. Matt Crawford offered to help add this.
- Should there be a mechanism to retrieve routing table information
(e.g., routing socket). Comment was made that this is beyond scope
of this specification. Should be in another document.
------------------------------------------------
Tunneling Spec / Alex Conta
------------------------------------------------
Changes since last version:
- Replace term recursive tunneling with nested tunneling.
- Add text to ICMP related to nested tunneling packets.
- Clarify that refers to point-to-point tunnels only.
- IPv6 tunnels must end in a unicast address.
- Clarified security section to discuss use of security headers and how
they are processed.
- Clarified usage of ICMP packet too big to max (576, tunnel MTU).
- Typos fixed and other small changes.
Would like to forward to IESG. No one had any objections to moving this
document forward. Document editor will submit to IESG for a proposed
standard.
------------------------------------------------
Header Compression spec / Micke Degermark
------------------------------------------------
Changes from previous version (v01->v02)
- Packet types FULL HEADER, COMPRESSED_NON_TCP, COMPRESSED_TCP,
COMPRESSED_TCP_MODEL_TA
- Use of length fields
- UDP checksum not sent when zero
- 0-bit in TCP change mask. TIMPSTAMP options ruins compression
otherwise. When OPTIONS change, set 0-bit and send whole OPTION.
- Header request (for TCP)
- Hook for passing sequence numbers by additional header compression on
top of UDP.
- Small changes to demultiplexing procedure
- Defined the ranges of configuration. parameters.
Believes that point-to-point mechanisms are stable now and would like the
draft to go to proposed standard. CRTP draft relies on this draft.
There are still problems on multi-access networks. Will a separate
document be issued. Yes, but additional problems need to be solved.
There is now an implementation on BSD.
Document editor will do a working group last call.
------------------------------------------------
Host Anycast / Jim Bound
------------------------------------------------
Need for host anycast addresses to support cluster type of technology,
load balancing for servers, and need to support distributed process
migration.
Also support dynamic address reassignment for an existing network
connection for both TCP and UDP. Support multilink and multihoming
dynamic address changes. Support for nomadic computing.
Proposes to:
- Add "p" bit to mobile binding Update IPv6 destination option
- Use the replay protection and security inherent in IPv6 mobility
specification.
- Define the enhancements needed for implementations
Deering asked how these would be routed? Need to define ICMP extensions
to handle of routing of host anycast addresses. Discussion about need for
specifying routing behavior.
----------------------------------------------------
IPv6 Multicast Address Assignment draft / Bob Hinden
----------------------------------------------------
Published an internet draft with initial fleshed out IPv6 multicast
address assignments. Intent is to send this to IANA as initial list of
addresses to be published.
One issue raised by this document is that except for Neighbor Discovery
solicited node addresses, all of the other multicast address assignments
fit into the low order 32 bits of the IPv6 multicast address. This lead
to a discussion about 1:1 mapping between multicast addresses and MAC
addresses. Discussion about alternative of expanding address space to
include ND solicited node address or to shrinking it to not conflict with
other multicast mappings.
Hinden and Deering will propose to the mailing list that the ND solicited
node address be changed to fit into a longer prefix (reduce the unique
part to fit into less than 32 bits)
---------------------------------------------------------
Monday 7:30-10:00pm
---------------------------------------------------------
---------------------------------------------------------
8+8 Addressing Proposal / Mike O'Dell
---------------------------------------------------------
Motivations
- IPv6 gives us a bigger version of a problem we currently don't solve
- Need aggressive topological aggregation going forward
- CIDRv6 isn't the answer for several reasons
o CIDR efficiency decays over time
o Multihomming is become more and more prevalent
o Forced renumbering will succumb to market pressure (e.g., won't
happen)
Origins of the Proposal
- Old idea , Doesn't claim to invent.
- XNS certainly had the locator and identifier idea
- IPv4 went the other way
- Personally believes that XNS got it right
- Others have discussed this before in IPng discussions
- This work was catalyzed by an email from Dave Clark
Important Notions
- Split address into two pieces
- One part reflects topological attachment to the Global Internet
- One part is topologically-invariant, known as an "End System
Designator" or ESD
- Current proposal divides the 16 bytes in half, hence "8+8"
- Strong distinction between "public topology" and "private topology"
- The site is the fundamental unit of attachment to the global
internet.
- Large Structures, fundamental large-scale aggregation object
- Deep equivalence of rehoming and multihoming (Fall back to alternate
path is a type of rehoming).
- Provides for transparent rehoming of Sites and Resellers
o End tyranny of CIDR
- Make multihoming an explicit service
o Upstream providers have to do something explicit to heal failures.
o Users pay for it.
- Dynamic Insertion of Routing Goop by border routers
o End systems don't usually have to know own routing goop
o Certainly "can" know it, but site border routers can impose exit
policy
- Upward delegation of DNS
o Automatic propagation of Routing Goop for Site-external
resolution provides for easy delegation of IN-ADDR.APRA inverse
lookups
End System Designators Properties (ESD's)
- Globally Unique (but no more than IPv4, IEEE MAC is good enough)
- Designates an End System interface - real or virtual
- End systems may be designated by multiple ESD's
- An ESD may not necessarily designate a particular physical computer
o Neighbor discovery provides for virtual address translation
o Service location possibilities
- ESD's are not guaranteed to be perfectly time-invariant
o Altered only by some site internal topology changes
Structure of ESD's
- 15 bits of Private topology partition
32,768 distinct partitions in the private topology
Population of each partition limited by IEEE MAC address space
Any of 32 hossts/partition gives million-host site
- 1 Mode bit determines format of 48 bit identity token
0 implies 48 bit MAC address
1 implies top bits of identity token imply subtype
- 48 bit identity token
Mode 0 : IEEE MAC 48 bit address
Mode 1 : 45 IETF Node ID which is densely assigned
Mode 2 : Identity token is officially assigned, non RFC1918 IPv4
address, right justified, zero padded
Other Mode values reserved
Structures for Sites
- Sites can be very large and complex.
- Sites are cheap, so needing more than one isn't really a hardship
- Lots of topology design options
- Public topology transit networks can also be sites
- PTP provides for network-internal designations of elements which are
part of public topology
Routing Goop
- RG is hierarchical locator
- Forest of spanning trees with flat-routed between root of the trees
- Conceptually flows outward from the originating large structure
Questions is this different from CIDR? Yes and no. Comment that this
this needs a different/better description. Very hard to understand in
it's current form. Long discussion. No clear outcome.
- Provides a framework for allowing the network to self organize
- Large Structures encapsulate significant topological aggregation
o Intentionally not a lot of them, only 14 bits allocated for LSID
o Limit worst-case flat-routing for top-level region
o Provide "routes of last resort" for default-free routers
Next version of document will be clearer and simpler. Mike O'Dell
thought it would be 6+2+8. Long discussion. Many questions. Chairs
will make a decision on how to proceed.
---------------------------------------------------------
Alternative Addressing Architectures / Masataka Ohta
---------------------------------------------------------
Complete Separation between Locators and ID
| 64bits | 64bits |
+---------------------+----------------------+
| ILOC | IID |
+---------------------+----------------------+
^ ^
| |
Locate (structurally subnet) |
in the global internet |
|
Identify a host with global Internet
Wrote ID a year ago <draft-ohta-ipv6-addr-arch-00.txt> that is available
at:
ftp://ftp.jain.ad.jp/pub/ids/draft-ohta-ipv6-addr-arch-00.txt
Problem with Mikes 8+8
- ID's have no hierarchical structure
- 48 bits are not enough for globally unique ID
Warts with Site Renumbering
- The locator of the hosts in the site changes
- Intra-site topology is unaffected
- Global unique ID which depends on site local topology is fine
Warts with Mobility and Multicast
- Encapsulation (MTU)
- Subnet model at foreign subnet
- Multicast addresses are location independent
- IDs must be globally unique independent of site local topology
Topology Independent ID
- Removes mobility warts
- Removes multicast warts
- Enables full process migration
- Enables site renumbering, of course.
- Thus, is the way to go.
Discussion comparing this proposal with 8+8. Conclusion is that they are
very similar.
Deering concluded that there could be separation between global info,
site info, and identifier.
-------------------------------------------------------
Multihoming / Source Address Selection / Steve Deering
-------------------------------------------------------
There was much discussion of this topic on the mailing list over the past
few months. Deering presented a particular model of a multihomed host,
in which interfaces are grouped by links, links are grouped by sites, and
sites are grouped into the global scope.
Discussed the weak and strong models of multihomed hosts:
- strong: (1) a host must not send a packet whose source address
does not belong to the origination interface.
(2) a host must not accept a packet whose destination
address does not belong to the arrival interface.
- weak: (1) a host may send a packet whose source address belongs
to any interface on that host.
(2) a host may accept a packet whose destination address
belongs to any interface on that host.
Multicast uses strong model -- necessary for source-sensitive multicast
routing, and to avoid duplicate reception.
Concludes that unicast SHOULD use weak model, but with source-address
selection rules that ensure that source address differs from origination
interface address only in unusual circumstances, e.g., when responding to
a ping of a receive-only interface.
Noted that the weak model is "less weak" in IPv6 than in IPv4 -- even in
the weak model, must not violate IPv6 address scope constraints (link-local,
site-local). However, this does *not* mean that source and destination
addresses must have the same scope, and Deering recommended not adopting
such an unnecessary constraint.
Strong support for weak addressing model with strong scoping rules.
Expects to have a draft in early part of new year.
---------------------------------------------------------
Interface ID Proposal / Steve Deering
---------------------------------------------------------
Discussion on KRE's draft. Now that current API drafts don't use
addresses to identify interfaces, this may not be needed. Discussion.
Deering took poll. No one supported keeping proposal. It will not be
moved forward.
---------------------------------------------------------
IPv6 MIB / Dimitry Haskin
---------------------------------------------------------
Updated MIB2 to IPv6. Allows to implement IPv6 MIB without requiring any
changes to the SNMPv2 SMI and compliant SNMP implementations. Drawback:
IPv6 address as an instance-identifier uses 16 sub-identifiers.
IPv6 (network layer) interface identification
- An 32 bit integer in the 1 to 2147483647 range
IPv6 MIB Groups
- IPv6 General
- ICMPv6
- UDP for IPv6
- TCP for IPv6
IPv6 General Group
- ipv6IfTable - Info on entity IPv6 interfaces
- ipv6IfStatsTable - Info on traffic statistics
- ipv6AddrPrefixTable - Info on address prefixes that are associated
with the IPv6 interfaces.
- ipv6AddrTable - Addressing information relevant to the entity's IPv6
interfaces
- ipv6RouteTable - Contains an entry for each valid IPv6 unicast route
- ipv6NetToMediaTable - IPv6 address to media address equivalencies
ICMP, UDP, TCP groups contain info on protocols, changed to include IPv6
addresses.
---------------------------------------------------------------
Thursday 1:00-3:00pm
---------------------------------------------------------------
---------------------------------------------------------------
Router Alert Option
---------------------------------------------------------------
Discussed briefly and group agreed to do a working group last call.
---------------------------------------------------------------
IPSEC
---------------------------------------------------------------
Heard rumor that IPSEC w.g. was considering changing IPSEC to not include
the flow label. Working group thought that it was important that this
change be discussed in the IPng working group prior to any change in
IPSEC.
---------------------------------------------------------------
Report on UNH Interoperability Event
---------------------------------------------------------------
Tested base spec, neighbor discovery, routing, MTU path discovery,
applications, and tunneling
Participants included: DEC, SUN, HP, IBM, Bay Networks, Cisco Systems,
WIDE, FTP Software, Sumitomo ,Fujitsu, Hitachi, and INRIA.
Most implementations supported basic specifications, neighbor discovery
was supported by 2/3 of participants. Serious problems were found less
than 1/4 of participants.
Future plans for IPv6 testing will be IPv6 testing at Connectatheon 1997
(March 1-6, 1997) and Network+Interop - Las Vegas (first week of May
1997).
---------------------------------------------------------------
Moving Base IPv6 Specs to Draft Standard / Steve Deering
---------------------------------------------------------------
Discussed whether w.g. thought we should advance basic protocols to Draft
Standard. Mentioned that we will have to show evidence of
implementations of all features. Question about impact of 8+8 proposal.
Chairs agreed to generate a list of changes which are being considered to
the basic specifications.
---------------------------------------------------------------
8+8 Proposal
---------------------------------------------------------------
Chairs proposed to allocate a Format Prefix for 8+8 addresses.
Implementations would have special pseudo checksum rules for this FP.
Would allow us to experiment with 8+8 without making a final commitment.
Discussion about impact of using 8+8 proposal on various parts of IPv6
architecture. Issues raised include:
- IPv6 over Foo
- DHCP impact
- TCP pseudo checksum calculation
- DNS changes
- How routers would put new "Routing Goop" in addresses
- Size of identifier
- Are MAC addresses used as identifiers are globally unique
Chairs proposed to hold a interim meeting before the next IETF to discuss
8+8 in more detail. Working group agreed. Details to be announced on
mailing list.
-----------------------------------------------------------------
IPv6 Packets over IPv4 Networks without Tunnels / Brian Carpenter
-----------------------------------------------------------------
Brian Carpenter presented an overview of the draft written by Cyndi Jung
and himself. The basic notion is to use an IPv4 multicast network as a
local link for IPv6. Isolated IPv6 host just runs, it does not need a
configured tunnel or IPv4 compatible addresses.
MTU size default is 1480 (1500 - IPv4 header size). Router
advertisements can change this. Alternative is to use "local IPv4 MTU"
minus "local IPv4 header size". Probably not necessary because 1480 is
likely to work over most multicast links. Comment multicast may be
running over tunnel so 1460 might be better.
Frame format shows IPv4 header over an IPv6 header. Proposes New
protocol identifier to identify these packets. Comment that this may not
be necessary.
Link local address. Stateless autoconfig works as normal. Suggest
normal 80 bit prefix FE80::. Use zero padded IPv4 address of host as 48
bit token. This seems more consistent than using 96 bit prefix and 32
bit token. Could easily be adapted to 8+8 token.
Address Mapping:
- Unicast : Neighbor discovery conveys IPv4 address around as link
layer address.
- Multicast: Use last 3 bytes of IPv6 multicast address as the last 3
bytes of IPv4 (pseudo link layer) multicast address. If no IPv4
multicast support, there is a possible kludge using IPv4 broadcast.
- Another proposal (Steve Deering) would be to configure host with
IPv6 host with unicast address of IPv6 router and run ND over this
tunnel.
Issues:
- Pad to 64 bit align the IPv6 header
- MTU = 1480
- IPv4 TTL
- Token Length (32 or 48)
- Drop the broadcast kludge
- Drop the NBNA note
- Enumerate multicast groups for ND
- Define scaling limits
The working group encouraged the authors to revise the draft and to
continue discussion in the ngtrans working group.
----------------------------------------------------------------
Multicast Routing / Thomas Narten
----------------------------------------------------------------
Asked if we know what we are doing with multicast routing. Deering
answered that he needs to write a document on how to generically
(e.g. protocol independent) handle Multicast routing
Deering mentioned that the decision was made to not port DVMRP to IPv6
because the plan it that unicast and multicast routing topologies should
be the same. We should concentrate on multicast routing protocols that
utilize the unicast routing table.
PIM Dense and Sparse mode currently handle IPv4 and IPv6 multicast.
Today people should use PIM for IPv6 multicast routing.
----------------------------------------------------------------
Router and Network Renumbering / Geert Jan De Groot & Bob Hinden
----------------------------------------------------------------
Geert Jan De Groot
------------------
We have auto configuration, but can't renumber routers automatically.
Routers are still configured manually. Will network really be able to
be renumbered.
Renumbering is needed. Customers changing ISP's should not result in
additional prefix. ISP changing transit provider should have minimal
effect on customers (next level provider). Topology changes may make
renumbering needed. The number of routing prefixes is the most important
issues in the operation of the Internet. Also, Pilot-sites are asking
for real address now to avoid having to renumber.
Currently the are about 40,000 prefixes. There are 1800 autonomous
systems. There are only 1800 routing policies. Ideally there should
only one prefix per AS. Need some time of prefix redistribution
mechanisms. Also need to work on Pier problem (IP addresses in configuration
files, etc.).
Bob Hinden
-----------
Background
- Neighbor Discovery Provides Mechanisms to Assign Prefixes to Nodes and
Add / Delete Prefixes for Nodes
- Currently Routers Must be Configured with Interface Specific Prefix
Information
- Missing Piece is how to Configure Routers Automatically
Router Renumbering
- Internet Wide Router Renumbering
o Too Scary
o Focus on Site
- Functions Needed
o Initial Configuration
o Assign Prefixes (+ related parameters) to Interfaces
o Change Configuration
o Change Prefixes on Interfaces
o Delete Prefixes on Interfaces
o Work after Site Partition (e.g., Healing)
Basic Mechanism
- Periodic Multicast (~1-5 minutes) of Router Renumbering (RR)
Advertisement
o All Routers in Site process RR Advertisements
o Authentication is Very Desirable
- Two Multicast Addresses (with site scope)
o Router Renumbering Advertisement Address
o Router Renumbering Solicitation Address
- Router can Solicit RR Advertisement by sending RR Solicitation to RR
Solicitation Multicast Address
o When Needs Prefixes or Prefixes timeout
o When Partitioned is healed
RR Advertisement
- Contains One or More Sets of RR Info Each Set Contains:
o Operator
o "A" Prefix (128 bits) and Prefix Length (8 bits)
o "B" Prefix (128 bits) and Prefix Length (8 bits)
o Parameters
o Lifetime
o Precedence
o Max Hop Limit
o Other ?
Operators
- Add: On Interfaces that Match "A" Prefix / Length Add "B" Prefix /
Length / Parameters
- Change: On Interfaces that Match "A" Prefix / Length Change to "B"
Prefix / Length / Parameters
- Delete: Delete Prefix ("A") (and Parameters) from Interfaces which
Match "A" Prefix / Length
Misc
- RR Advertisement also includes a Sequence Number
o Increment Sequence Number when Contents Change
o Receivers can ignore Duplicates
Issues
- Should RR be Used to Do Initial Interface Prefix Assignment?
- Would "Current Prefix State" Messages be Simpler than Change State
Operators?
- Relationship to 8+8 Proposal?
Summary
- Proposal would Make it very Easy to Add New Global Prefix to Site
o Add Operation with Match on Constant Part of Prefix on all
Interfaces
- Change and Delete also Easy
- Supports Individual Interface Changes
o Match on Link Local Interface Address with Prefix / Length (128)
There was general interest in pursuing this work. An internet draft will
be written.
-------------------------------------------------
Inter-Domain Routing (IDRP, BGP5, ?) / Bob Hinden
-------------------------------------------------
Hinden raised the issue that there was not very much progress on
implementations of IDRP for IPv6. He mentioned that he had heard from
ISP's that they did not want to deploy IDRP and would prefer an update to
BGP.
Joel Halpern added that the plan in the routing area was to not do
another version of BGP. IGRP was to be the replacement for BGP.
Dave Katz suggest that it would be very easy to add options to BGP4 to
carry IPv6 interdomain routes. Dimitry Haskin said it would be very easy
(two weeks work) to do this in his implementation, where doing IDRP would
be a major effort. Working group thought this would be a good thing to
pursue. Dimitry and Dave agreed to write up a proposal.
----------------------------------------------------------------
Address Prefix Notation / Alain Durand
----------------------------------------------------------------
Raised issue with how IPv6 addresses with prefixes should be written.
Currently in the RIPE registry they are not being written consistently.
Examples
::/96
FED0::/80
5F06:B500:/32
This needs to be added to the next version of the addressing architecture
document. Will be added to list of changes for this document.
----------------------------------------------------------------
Unspecified Address in Neighbor Discovery / Dan Harrington
----------------------------------------------------------------
Use of unspecified address as source address is only defined for DAD,
using multicast destination address (network + link).
Should expand ND input packet validation rules to silently drop such
packets. Group agreed to change this in next version of ND.
----------------------------------------------------------------
Tag Switching use of Flow Label
----------------------------------------------------------------
No one attended the meeting who wanted to talk about this. The working
group said it was important that any proposal for changing the definition
of the IPv6 flow label should be done here. The decision to change the
semantics of the IPv6 flow label belongs to the IPv6 working group.
----------------------------------------------------------------
Mobile IP Request / Charlie Perkins
----------------------------------------------------------------
Mobile IP for IPv6 would like to be able to send a request to use an
anycast cast address to all IPv6 mobile IP home agents. Approach is to
tunnel to an anycast address for home agents with the inter packet
addressed to the All Home Agents multicast destination with link scope.
+---------------------+-----------------+
| Anycast | Multicast |
+---------------------+-----------------+
| Subnet prefix + 000 | All Home Agents |
With Hop limit = 1
Discussion about requiring all IPv6 routers to support mobile IP. Could
also be done by allowing tunnels to be created to anycast address (which
is not supported in current draft).
The result of this discussion was to modify the tunneling draft to permit
tunnels to be set up to anycast addresses to handle this function.
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------