IPng Meeting
Washington, DC IETF
December 8-12, 1997
----------------------
Chaired by Steve Deering (Cisco) and Robert Hinden (Ipsilon). Minutes
taken and prepared 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
- Generic Packet Tunneling in IPv6 Specification / Dec 96 (IESG Comments
received 11/25/97, waiting for new ID) AD reported that this should
resolved soon.
- Transmission of IPv6 Packets over Ethernet Networks / Nov 97 (IESG:
Resolve Global/Local bit setting issue)
- Transmission of IPv6 Packets over FDDI Networks / Nov 97 (G/L)
- IP Version 6 Addressing Architecture / Nov 97 (G/L)
- An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments
from Registries)
IETF Last Call completed for Experimental
- IPv6 Testing Address Allocation / Nov 97
IETF Last Call completed for Informational
- IPv6 Multicast Address Assignments / Nov 97
Submitted to IESG for Proposed Standard
- IPv6 Router Alert Option (IESG returned, need new ID)
- MIB for IPv6: ICMPv6 Group / Jun 97
- MIB for IPv6: TCP / Jun 97
- MIB for IPv6: Textual Conventions & General Group / Jun 97
- MIB for IPv6: UDP / Jun 97
- Transmission of IPv6 Packets over Token Ring Networks / Nov 97 (G/L)
- IPv6 over PPP / Nov 97 (G/L)
- IP Header Compression / Nov 97
Submitted to IESG for Informational
- Advanced Sockets API for IPv6 / Jul 97
Submitted to IESG for BCP
- TLA and NLA Assignment Rules / Nov 97
Status of moving base specs to Draft Standard / R. Hinden
---------------------------------------------------------
BASE SPECS TO DRAFT
- IPv6 Specification
o MTU Issue Resolved (1280 octets)
o New Draft Issued
o Starting to Collect Implementation Info
- ICMP
o New Draft issued w/out IGMP messages
o Starting to Collect Implementation Info
- Path MTU Discovery
o Starting to Collect Implementation Info
Will be sending questionnaire about implementation info 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
- Updated Draft based on IANA Comments
o Added Established Provider Criteria, Registration Fee, and Auction
for New Organizations
- Submitted to IESG for BCP 11/11/97
- Considerable Controversy!!!
- Waiting for IESG Direction on how to proceed
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
- Bad guy sends out a single bogus Router Advertisement (RA)
- RA contain prefix info option with Valid lifetime of zero
- Host interprets RA to mean address is now invalid, stop using it
immediately.
- Upper layer protocols may stop working (e.g., all TCP connections
break) This is not a hard requirement in spec but some implementations
may do this]
Not like other Denial of Service attacks
- No comparable "hit and run" packet in IPv4 (or IPv6) as dangerous
- Once upper layer have aborted open connections, no recovery is
possible.
- Problem must be fixed in IPv6 is to be no more vulnerable than IPv4
Proposal 1
- If received with Valid Lifetime > 2 hours or greater than lifetime in
cache, process as before
- Attempts to reduce the valid lifetime to value less than 2 hours and
less than lifetime of cached entry require special processing.
[pseudo code for algorithm]
This proposal limits removing prefix to 2 hours units. Can't remove
one in shorter time.
Proposal 2 [from Erik Nordmark]
- Avoid defining special mechanism to handle this one specific denial of
service attack.
- Rely on robustness of transport protocol to limit impact of zero
lifetime denial of service attack.
- Already have many denial of service attacks (both IPv4 and IPv6) that
cause packets to be blackholed.
- Transports (e.g., TCP) are robust in such cases by continuing to
retransmit (e.g., not allowing ICMP destination unreachable to
terminate connection)
- IP layer continues processing zero lifetime as
specified inRFC1971, but transport layer is not required to terminate
connections using addresses that become invalid.
- IP layer on host would blackhole packets form invalid source address
(i.e., no violation of existing spec).
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 that 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
- "M" bit indicates DHCP should be used to obtain addressing
information.
- "O" bit indicates DHCP should be used to obtain other (i.e.,
non-addressing) information.
Proposal
- Do away with "O" bit
- Single bit would say "do" or "don't" use DHCP
Rational
- Separate bits complicates protocol
- Having "O" bit raises issue of what to do if DHCP server returns DHCP
option that "O" bit says shouldn't be obtained
- Benefit unclear. Behavior of the two bits can be obtained by having
DHCP server decide what information it wants to give out.
J. Bound thinks we only need one bit. All that stateless is for is
addresses and link parameters. Critical parts 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 w.g. 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 w.g. IPng will continue this in the Friday session.
Default value for valid lifetime in Prefix information options:
- RFC1970 says default preferred lifetime is 7 days
- RFC 1970 says default valid lifetime is infinity
- Value of infinity problematic:
o Suppose system administrator decides to timeout prefix
o Subsequent Router advertisements advertise small lifetimes,
eventually going to zero.
o Lifetime of zero must be advertised forever, to be sure nodes that
are disconnected from the link receive updated value on
reconnection.
o Danger that any prefix advertised with infinite Lifetime will be
hard to completely purge from network.
- Propose setting default value to 30 days
o System administrator is free to change this value; 30 days is the
default value in the absence of input from system administrator
o Having an address without properly functioning router is of limited
benefit; if router is functioning properly, it will be sending out
proper Prefix Advertisement options.
Consensus to adopt this proposal.
Summary of Open Issues
- Protection from zero life denial of service attacks.
- If Proposal 1, is 2 hours the right time? No objections to 2 hours.
[Editor's note: Remaining issue to be resolved at Thursday w.g. session
before moving this to draft standard]
Mobile IPv6 Status / D. Johnson
-------------------------------
High-level overview of operation:
- Care-of addresses from IPv6 address autoconfiguration
- Mobile node sends its own Binding Updates
- Used for correspondent nodes and home registration
- Nodes cache bindings in a Binding Cache
- Correspondents route own packets directly to mobile node
Current spec is draft-ietf-mobileip-ipv6-04.txt
One implementation done so far (CMU). Other implementations in progress?
Editorial Changes:
- Added a statement of some non-goals of the protocol in Section 1.
- Added definition for home link and home subnet prefix, replacing
the old term home subnet.
- The new terms foreign link and foreign subnet prefix likewise
replace the old term foreign subnet.
- Moved the Comparison with Mobile IP for IPv4 section to earlier
in the document (now Section 2)
- Added specific in Section 4 listing the fields conceptually
present in each Binding Cache entry and in each Binding Update
List entry.
- Added Section 12 on IANA Considerations.
- Replaced the description of specification language keywords,
MUST, MAY, SHOULD, etc., with the new standard reference to
RFC 2119.
- Updated the References to point to the most recent version of
each cited RFC or Internet-Draft.
Binding Update Option Changes:
- Increased the Lifetime field from 16 bits to 32 bits, to allow
consistency with other lifetime values used in IPv6.
- Replaced the Home Link-Local Address Present (L) bit and the Home
Link-Local Address field with a new mechanism implemented by the
ID Length field:
o Home agent becomes home agent for all on-link home addresses
with this interface ID
o Proxies for mobile node in Neighbor Discovery with this ID
o If ID Length is 0, only use single specific home address
o Mobile node may send separate Binding Updates for each ID if
different
- Change sending of Binding Update to a mobile node's previous
default router from SHOULD to MAY.
- Clarified handling for packets addressed to a mobile node's
link-local address or site-local address:
o Data packets are not forwarded to the mobile node while away
from home.
o Home agent returns ICMP Destination Unreachable, Code 3, for
any received.
o Home agent continues to defend for Neighbor Discovery.
o As the use of link-local addresses or site-local addresses
evolves over time in IPv6, this disposition of such packets
may need to change, however.
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:
- Changed the Option Type value to now ignore rather than returning
an ICMP error if not recognized.
- Increased the Lifetime field from 16 bits to 32 bits.
- Increased the Refresh field from 16 bits to 32 bits.
Binding Acknowledgment Option Format:
+-+-+-+-+-+-+-+-+
| Option Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Status | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Binding Request Option Changes:
- Changed the Option Type value to now ignore rather than returning
an ICMP error if not recognized.
- Added a discussion of sending Binding Requests in Section 7.6.
- Added a discussion of receiving Binding Requests in Section 9.11.
Binding Request Option Format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Home Address Option Changes:
- Added details of how and when Home Address option is added to a
packet when sending:
o TCP/UDP/etc. generates packet as normal.
o In IP (Mobile IP), if the Source Address is not home address,
just send packet normally.
o Otherwise, insert a Home Address option:
+ Copy Home Address field from Source Address
+ Change the Source Address to care-of address
+ Must be performed before outgoing IPsec processing, if any
- Added details for inbound IPsec processing:
o Must be performed before any packet modifications for Home
Address option processing.
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:
o Dave Johnson, dbj@cs.cmu.edu
o Charlie Perkins, cperkins@eng.sun.com
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 w.g. 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 w.g. summary relevant for IPng
Since last meeting
- In Munich, much confusion
- Action items
o Generalize the architecture
- ATM Split document into two
o draft-ietf-ion-ipv6-oo.txt
o draft-ietf-ion-ipv6-atm-00.txt
- Other IPv6 related drafts
o draft-conta-ion-ipv6-fr-00.txt
o draft-conta-ion-ipv6-ind-00.txt
General Architecture
- Assume general NBMA "cloud"
o Capable of p-p links, pt-mpt links, may/may not native multicast
- MBMA could be ATM, Frame Relay, IPv4, ...
- MARS? NHRP?
Major New Item / Shortcut suppression
- Request in Munich for host controlled shortcut suppression
- How to convey this indication in-band?
- Original default, discover shortcut whenever a "flow" is detected
- Need indication of "flows" that should not have this default action
applied
- Proposal for broad interpretation of flow label field
Interpretation of Flow Label
- Flow label == 0
o Apply default IPv6/NBMA flow-detection and short cut discovery
- Flow label != 0
o Do not apply IPv6/NBMA flow-detection and shortcut discovery by
default
- Support whatever other packet forwarding, queuing, and/or scheduling
rules may have been negotiated with each router along the path
- Perform best effort in absence of negotiated service
- No additional semantic restrictions
Discussion how this would interact with other usage of flow label.
C. Huitema pointed out that it is backwards. Flowlabel 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
- Media specific companion document to draft-ion-ipv6-00.txt
PVC rules
- Standard LLC/SNAP encaps, with IPv6 PID (null encapsulation
allowed/negotiable)
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 w.g. drafts and pursued there.
Router Renumbering / M. Crawford
--------------------------------
RR Goals
- One step changes to the set of prefixes in use site-wide
o Including ND timers and flags
- Spectrum of finer-grained operations, down to a single interface of a
single router
- Reliability
- Security
RR Basics
- Carried in ICMPv6, type = TBD
- two codes: Command & Result
- Built-in authentication and & replay protection, or use IPSEC
- "Dry-run" mode to simulate a Command
- "site-conscious" can apply command to subset of multi-sited router
RR Command Structure
[Using ABNF of RFC2234]
- CmdPkt = Header *PCO AuthData
- PCO = Op MatchPrefix *UsePrefixPart
- UsePrefixPart =
cut & paste info to combine old & new bits
Mask & Flags to set ND PIO flags
ND RA timers
New Prefix bits
RR Result Structure
- ResPkt = Header *MatchReport AuthData
- MatchReport identifies a match by
Which PCO in the corresponding Command packet
Interface
Prefix
- The new prefixes, if any, can be inferred
Lacking in current draft
- Examples!
- Asymmetric keys??
- Is message processing section sufficiently rigorous
- Other error contradictions?
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?
- One proposal: draft...-aaaa-00.txt
- Main feature: indirection
AAAA = prefix length + suffix + name of prefix
- Three questions:
o Do we need this?
o Shall we use the same record number?
o Shall we maintain upward compatibility?
Needs, Let's take an example
+--------+ +--------+
| | | |
| TLA-1 | +--+ TLA-2 |
| | / | |
+---+----+ / +----+---+
| / |
| / |
+---+----+ / +----+---+
| +-+ | |
| ISP-A | | ISP-B |
| | | |
+----+---+ +---+----+
\ /
+--+--------------+--+
| Site |
+--------------------+
|
Host
- We will Consider
o Change provider,
o Network multi-homing
o Provider renumbering,
o Provider multihoming
What we have today will not scale
- For each host, 3 records
TLA1/A/SiteA/LinkID
TLA2/A/SiteA/LinkID
TLA2/B/SiteA/LinkID
- Change provider
Change all records
- Network multihoming
Duplicate record
Provider renumbering
Phone call to site
- Provider multihoming
Duplicate prefixes
Local copies
Using the new format solves the problem
- For each host, one record
Link/ID + net.site.com
- For the site
NLA-A + net.ips-a.net
- Change provider
update net.site.com/AAAA
- Network multihoming
Two AAAA records for net.site.com
- Provider renumbering
- Provider multihoming
Update provider AAAA record
Question 2 - Resource Record Number
- Using new RR type
o Allows parallel deployment,
o But resolvers will never look for two records
- Use same RR type (AAAA)
o Will break old software
o Forces transition to new structure
Question 3 - Format compatibility
+---+--------+-------------+
| L | Suffix | Domain Name |
+---+--------+-------------+
+-----------------+---+-------------+
| 128 bit address | L | Domain Name |
+-----------------+---+-------------+
+-----------------+---+-------------+
| 128 bit address | 0 | ...... |
+-----------------+---+-------------+
- If compatible, two phase deployment
- Longer records per host (128 bits v.s. 80)
- Sill wins over current AAAA record (multihoming)
A decision on AAAA record?
- Shall we
o Leave RFC1886 alone, or
o Modify & recycle to Proposed Standard?
- If we modify:
o Shall we keep the AAAA record?
- If we modify the AAA record
Shall we adopt the new format (draft) ?
or shall we maintain compatibility ?
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
- IN-ADDR.ARPA poorly maintained, will IPv6.INT be better?
- Maintenance of delegations will be more difficult in the expected
frequent renumbering environment of The Future.
- For access control, or even logging, IP6.INT provides nothing but a
hint anyway.
Features
- PLUS: Routing system takes the place of IP6.INT delegations
o Always current
- PLUS: A meaningful TTL is usually available from Auto config or DHCP
- MINUS: Target must be up and reachable to do a lookup
o But is it meaningful to say a certain FQDN is associated with an
address, when it isn't up?
Status of -01
- Query & Response processing: done
- Rules for TTL field: done
- Added terminology section; guidelines & discussion; security
considerations, IANA considerations.
- Open issues:
o Possible change to DNS client view
o Negative caching
- Authentication: new issue
DNS Delegation and Renumbering
------------------------------
Two General Modifications to DNS
Problems
- aaaa-00 DBIT records
o Rely on wildcard records which produce intermediate data of no
later use
- dns-reverse-lookup-00 DBIT records
o Require lower zones to be renamed on renumbering
* Even DynDNS can't pull off that trick
New Proposal
- Previous proposal involved only new RR types and new resolver/additional
section processing rules
- I propose two extension to DNS which have uses unrelated to IPv6
Non-Terminal CNAMEs
- ... or whatever you want to call them
- Translate a suffix of the queried domain.
- Query to be repeated with same initial part of translated suffix
- Examples
225.131.in-addr.arpa ZNAME in-addr.final.gov.
foo.com ZNAME foo-division.bar.com
Counted Bit-Strings
- Length-of-Label counts bits, not octets.
o Pad data to octet, of course
- To be considered: as a sequence of 1-bit labels (at an almost 16x space
saving)
- Consider it a form of compression
+------+------------------+------------------------+
| 01xy | bit count | bit string |
+------+------------------+------------------------+
What they can do for IPv6
- Simplify and shrink synthesized AAAA records
- Enable reverse zones which are nearly hands-free maintainable across
"renumbering events."
o Non-terminal ZNAME > delegation
o Counted bit strings > N x (single purpose RR)
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
- Storing all reverse records under name like
0102030405060708090a0b0c0d0e0f10
o Is impossible to maintain
o Is impossible to secure
- Addresses consist of fields that reflect the delegation authorities,
reverse lookup should maintain this information.
- It is impossible to know the size of the next delegation unless it is
fixed or it is explicitly stated.
DBIT (delegated BITs) record
- RBATA contains last bit delegated, DNS name of the authority
assignment has been delegated to
- Name on DBIT record encodes prior delegations
o First byte is length of bit field
o Subsequent bytes is the bit field
o Names are stored as binary values
- Examples: (in hex)
o 08aa.ip6.ing IN DBIT 20 ripe.net
- Last bit delegated == 128 delegates all remaining bits and
corresponding DBIT record is expected in the domain delegated to
- Last bit delegated == 0 is a EID/host DBIT record
DBIT Example
- Query for address aa2f:34:1::3fff:1234
- Server needs to query for the following DBIT records
o IP6.INT DBIT 8 iana.org.
o 08aa.IP6.INT DBIT 20 ripe.org.
o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example.
o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example
- 2000010000.0c0034.0c02f0.08aa.IP6.INT. DBIT 128
thorshofn.ismennt.is.example.
- 40000000003fff1234.thorshofn.ismennt.is.example. DBIT 0
sia.thorshofn.ismennt.is.example
Example 1: Query for address
- Ask server ipv6.int for DBIT record ofip6.int
o IN.INT DBIT 8 iana.org
o + NS records for iana.org + glue
- Now ask iana.org for 08aa.IP6.INT DBIT record
o 08aa.IP6.INT DBIT 20 ripe.org
o + NS records for rip.net + glue
- Now ask one of the ripe.net servers for 0c02f0.08aa.IP6.INT DBIT
o 0c02f0.08aa.IP6.INT DBIT 32 isnet.is.example
o 0c0034.0c02f0.08aa.IP6.INT DBIT 64 ismennt.is.example
o 20000020000.0c0034.0c02f0.08aa.IP6.INT DBIT 128
thorshofn.ismennt.is.example
DBIT Example (2)
- At this point all remaining bits are delegated now asks server
thorshofn.ismennt.is.example. for
40000000003fff1234.thorshofn.isment.is.example
o 40000000003fff1234.thorshofn.isment.is.example DBIT 0
sia.thorshofn.ismennt.is.example. for
- Now server has all the DBIT records in and can generate an answer
that looks like:
o 80aa2f003400010000000000003fff1234.IP6.INT DBIT 0
sia.thorshofn.ismennt.is.example.
- The last answer is not signed but the server can return to the resolve
all DBIT records used to allow signature verification.
DNS Impact of DBIT records
- DBIT ignorant servers and resolvers will ask for
80aa2f003400010000000000003fff1234.IP6.INT
- DBIT aware server needs to break address requested into the different
fields
o Servers SHOULD be able to longest prefix match on DBIT records in
cache
o Servers need to issue multiple queries to generate correct answers
o Servers need to be able to merge multiple DBIT records into one
answer.
- DBIT preprocessing is similar to KEY chain verification in DNSSEC.
Advantages of DBIT records
- Allows delegations to take place on any bit boundary
- Explicitly state the delegations and size of delegations
o Allows full verification of the bindings
- Fits well with caching name servers
- End sites do not have to resign any DBIT records when renumbering
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 6
months.
Gethostbyname update to RFC 2133 / B. Gilligan, J. Bound
--------------------------------------------------------
RFC1233 Update
- flags now
- Freehostent MUST always be called!
- Flags Default (continues ....)
7. Agreement on change by hostbyaddr()
8. Suggest we use AI.Default as a system default. Also suggested to
author off-line -> xxxxx
10. Name change suggestions:
getdynhostbyname()
Freedynhostent()
getdynhostbyaddr()
Suggestion to use "node" instead of "host"
11. Add new AI_Flags to getaddrinfo()
Warning - TOG/XNET owns this spec ????
Thanks to Bob, Sue, Jim, & 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
- Route for the direct patch
- No information about the reverse path
- Source-routing is not a solution
- Many (most?) routes are asymmetrical (difficult to debug)
- Can go through firewalls...
Proposed Solution
- Based on RFC1394 for IPv4 & IPv4 Record Route option
- Define an hop-by-hop option processed by routers on the direct and the
reverse path.
- Define a new ICMP traceroute message
- 4 different strategies can be used
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
- Originator send ICMP echo request to target with traceroute hop-by-hop
- Routers store information within the option
- Target send ICMP echo reply with traceroute hop-by-hop option
initialized with data from the received packet.
- How many routers can be recorded?
o min MTU 576 => up to 21
o min MTU 1200 => up to 47
- OK for small networks, not enough in the general case
[figure of two packet traceroute]
Strategy #2 Limited Traceroute
- Originator specifies to record the direct path or the reverse path.
- Originator includes a boundary indication
- Packet is sent with Hop Count set to 255
- Routers should record information iff current Hop Count <= Boundary
[figure of limited traceroute]
Strategy #3 Debug Mode
- Originator set a "debug flag" in the hop-by-hop option
- Routers send their information in a new ICMP traceroute message back
to the originator.
[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
that 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 w.g. 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 & Address Auto-Conf
- Document editor will do wg last call for advancement to Draft as soon
as updated drafts are out.
Unicast Aggregation Formats draft
- Author will add motivations section based on last call discussions.
[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
- After discussions with lots of IESG folks and other interested parties
this week, decision is to form operations area WG to progress rules
document. Allison Mankin and Erik Huizer will co-chair working group.
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
- An ECN-capable bit set by the origin transport protocol (for
incremental deployment)
- An ECN bit set by the router (instead of dropping the packet)
(When the buffer has not overflowed, and the ECN-capable bit is set,
and the router would otherwise drop the packet because of the RED
algorithm, base don the average queue size.
Where would the bits come from?
- The IPv4 TOS byte and/or the IPv6 traffic class byte
- Our original proposal was only in terms of IPv6
- IPv4: The current draft of draft-ellesson-tos-00.txt includes the CE
and ECT (ECN-capable transport) bits
- What would be the time scale of making this decision?
- Where? Intserv/diff-serv? or IPng?
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?
- The One-bit approach: The single bit would have two values:
"ECN-Capable", and "either not-ECN-Capable, or Congestion
Notification".
- The ECN-Capable functionality is needed to allow a viable incentive
for incremental deployment of ECN-aware hosts.
- Robustness issues for one bit approach:
o Default setting MUST be "either non ECN capable, or Congestion
Notification"
- The receiver has to know in advance that the sender is sending all
packet with the bit set as "ECN-Capable".
Why not Source Quench?
- The delay difference (between RTT and part of an RTT) is not a
critical issue for most environments
- The ECN bit is applicable for multicast as well as for unicast
applications.
- With Source Quench, care must be taken not to add significant extra
traffic in times of congestion.
How would the router decide whether to drop the packet or set the ECN
bit?
- For ECN-capable packets, the router would set the ECN bit when it is
in the regime of using RED to "mark" packets probabilistically. When
the average queue size exceeds the maximum queue threshold, the router
would drop arriving packets.
- For most routers today, the packet drop rate is less than 10%. If
these routers deploy RED, they are therefore generally in the regime
of probabilistic marking.
Does ECN make it easy for evil applications to ignore congestion control?
- Already easy for "evil" applications to ignore congestion control.
Just use UDP, and add a little FEC to counteract the packet drop rate.
Or "turn off" congestion control for TCP.
- In the absence of congestion control in the end-nodes, a moderate
(less than 10%) packet drop rate is not, in and of itself, an effective
mechanism of congestion control, or an effective deterrent to any
application that wishes to "turn off" end-to-end congestion control.
- ECN does add another way that applications could ignore congestion
control, but setting the "ECN-capable" bit but ignoring the ECN bit in
received packets.
What applications would benefit from ECN
- Reliable multicast
- Real time flows with (fixed or adaptive) playback times
- Very short web transfers
- Low-bandwidth telnet connections
ECN Simulations and Experiments
- Simulations: the ns-1 and ns-2 simulators [floyd1994]
- Experiments: UCLA (Chris Chen, Hariharam Krishnan, Steve Leung, Nelson
Tang) has an ECN implementation in IPv6 FreeBSD. Using RED
implementation from ALTQ.
- The bits to use in the IPv6 header for experimental purposes?
IGMP for IPv6 / S. Deering
--------------------------
Based on IGMPv2 for IPv4 Spec (recently approved as proposed standard)
Changes of terminology from IPv4 version
- Host/Router/Node, Network/Link, etc.
- "multcast listener discover"
Uses ICMPv6 message types, not protocol ID #2
Uses Link-local source address for messages
- Link-Scope all-nodes multicast destination address for queries
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
- Tunnel minimum, maximum, and default MTU
- Frame format for IPv6 over IPv6 and IPv4 tunnels
- Interface ID for IPv6 tunnel interfaces
- IPv6 link-local addresses for tunnel virtual links
- Source/Target Link-Layer address option used in ND or IND over IPv6
and IPv4 tunnels.
MTU
- default tunnel MTU = ( physical underlying IPv6 interface MTU - tunnel
headers size)
o For Ethernet 1500-20=1480
- 1280 <= tunnel MTU < default tunnel MTU
Tunnel Packet Format
- IPv6 tunnel packets are encapsulated as:
o IPv6 packets
o IPv4 packets
Interface ID (token)
- The IPv6 tunnel pseudo-interface ID (token)
o Unique on the virtual link represented by the tunnel
- Method 1
o Use underlying physical interface identifier (e.g., EUI-64, EUI-48,
etc.)
- Method 2
o Based on random number - local, individual
7 6 5 4 3 2 1 0 (bit order
+-----+-----+-----+-----+-----+-----+-----+-----+
0 | Random Number | MBZ |
+ +-----+-----+
. .
. .
. .
7 | |
+-----+-----+-----+-----+-----+-----+-----+-----+
o 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
- Limit effect of renumbering in a site by ensuring that traffic local
to the site use site local addresses.
- Do this without requiring a two-faced DNS.
Proposal
- Advertise the global prefixes (w/ lifetimes) for the site in Neighbor
Discovery messages.
- The hosts use this information to maintain a list of the current site
prefixes.
- The host resolver (gethostbyname function) checks against list of
prefixes after resolving the name.
- When one of the addresses retrieved from the DNS matches one of the
site prefixes (i.e., the first N bits match) then replace with the
corresponding site local address.
Open issue 1 - Mobile nodes moving off site and have been using site
local addresses.
- Clarify in architecture: mobile is part of home site, not part of
visited site
- Site local packets (src or dst) over bi-directional tunnel to mobile
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
- Disable algorithm (in draft), or
- Christian H. proposal with random site ID in site local address
+-------+-------------------+--------+--------------+
| 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
- Flexibility - not all nodes in the site must have a site local address
- Limits denial of service attack?
- No need for two-faced DNS
- Site local address is ignored unless in same site
- If RRset contains global address matching a site prefix => Use site
local RRset
Open Issue 4 - Include or remove global addresses?
- Site local should be tried first by application
- Returning globals => accidentally using global when site local would
have worked
- No globals => site locals better work!
- Admin applications need to see content of DNS
Open Issue 5 - Encoding the exact semantics of advertisement:
- Note: Separate prefix option advertisement to assign site local address
- Should the site prefix be a separate prefix option (i.e., remove Site
PLength?
Open Issue 6 - Security considerations:
- Any node on the link can cause a denial of service attack by
advertising a bogus site prefix
- This is not any worse than other on-link DoS attacks.
Open Issue 7 - Assumes common SLA (subnet number):
- 16 bits in site local
- Must match in all global and the site local addressing plans
- Relax if site locals in DNS
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
- VRRP allows one router to back up another router transparently to
hosts
o Goal is to keep TCP connections from breaking
- Current Host OS's don't handle switching to a second router well
or at all
- Mechanisms such as Router Discover were not designed for this function
and are not widely implemented.
IETF
- VRRP being developed in IETF
o VRRP Working Group
o Current draft is: <draft-ietf-vrrp-spec-04.txt>
- Provides functions similar to Proprietary Protocols
o Cisco HSRP
o Digital IP Standby Protocol
- Work Includes
o VRRP Protocol
o VRRP MIB
o VRRP for IPv6
[Figure showing basic operation of VRRP]
VRRP Mechanisms
- Virtual MAC Addresses
o Mapping between Router IP Address and MAC Address
o Host Default Gateway stays the same
- VRRP Protocol and State Machine
o Determines which router is Master
o Sends Periodic Advertisements
+ Default is 1 second
o Backup takes over if three Advertisements not heard
Additional Detail
- Priority Allows control over which router backs up another
- Supports Loadsharing by setting Default Gateway in Hosts to different
VRRP Routers
- More sophisticated control can be done by dynamically changing
priority based on status of other interfaces
- Runs over Shared Media LAN's
- Authentication choices include MD5
Status
- Working Group Meet at this week's IETF
- Group agreed to move to Proposed Standard with small changes
- Work starting on
o VRRP MIB
o VRRP for IPv6
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 w.g. 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
- Allow a multihomed site to use other links for existing sessions which
have addresses derived from the provider on the failed link.
- Do not inject long prefixes into global routing.
- Do not tell ISP's how to run their busine$$es.
Three Magic Words
- Multicast
- Security
- Mobility
[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
- The "B" (for broken) flag
o Valid/preferred lifetimes unchanged
- Host action:
o Do not select this prefix for new communication if there's a
non-broken prefix available
o For existing communication, use IPv6 mobility as if host has moved
to A::S::HL
Wants discussion on mailing list.