Current Meeting Report

2.2.5 IP Version 6 Working Group (ipv6)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 21-Jan-02
Bob Hinden <>
Steve Deering <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Bob Hinden <>
Mailing Lists:
To Subscribe:
In Body: subscribe ipng
Description of Working Group:
IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) is intended to support the continued growth of the Internet, both in size and capabilities, by offering a greatly increased IP address space and other enhancements over IPv4. The IP Next Generation (IPng) working group was originally chartered by the IESG to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. Most of the tasks in that original charter have been completed, and the core IPv6 protocol specifications are now on the IETF standards track.

This charter focuses on completing the remaining work items and providing a home for IPv6 work that spans multiple IETF working groups. The working group is being renamed the IP Version 6 Working Group (IPv6) because it is a better description of the working group's focus.

The specific working group's ongoing responsibilities are as follows:

- Complete work from the original charter and follow-on work, as outlined below.

- Keep all IPv6 working group documents moving along publication / standardization track.

- Complete work from the original charter and follow-on work, as outlined below.

- Keep all IPv6 working group documents moving along publication / standardization track.

- Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups.

- Provide a home for IPv6-related work that doesn't fit in an existing IETF working group and doesn't merit a working group of its own.

- Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures.

The list of the working group's current work items is as follows:

- Revise and advance to Draft Standard the IPv6 Address Architecture document [RFC 2373]

- Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the policy aspects that are considered RIR issues.

- Complete work on recommended address-selection algorithms

- Revise ICMPv6 spec [RFC 2463] (scope-exceeded err, no error to redirect, editorial)

- Revise Generic Tunneling spec [RFC 2473] (add bidirectional tunnels)

- Update Basic and Advanced API specs [RFC 2553, RFC 2292]

- Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping

- Work on host-based solutions to site-multihoming problems (in coordination with multi6)

- Complete work on local IPv6 networking as part of IPv6 plug-and-play (to be coordinated with other WGs as appropriate, e.g., dnsext, zeroconf, etc.)

- Document IPv6 renumbering model

- Complete the IPv6 Node Information Queries spec

- Revise and update the base IPv4/IPv6 MIBs and produce a new consistent set of MIBs that cover IPv4 and IPv6 together. RFCs to be looked at together: 2011, 2012, 2013, 2096, 2851, 2452, 2454, 2465, 2466 and possibly 3019.

New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group.

The working group would welcome contributions on the following topics this is not an exhaustive list):

- Flow label standardization

- Solutions to other multihoming issues, beyond those specific to site-multihoming

- Integration of autoconfiguration, mobility, DNS, service discovery and other technologies to enhance IPv6 plug-and-play

- IPv6 dial-up issues relating to address assignment, use of Neighbor Discovery, etc. (not including AAA work)

- Specifications for IPv6 over additional media

- Host use of anycast; TCP use of anycast

- Support for multi-link subnets (single subnet spans multiple links)

- Scope-name discovery

- IPv6 protocol extensions to accommodate mobile wireless networks.

Goals and Milestones:
Jul 01   Revise IPv6 Address Architecture and resubmit to IESG for Draft Standard
Jul 01   Revise IPv6 Aggregatable Unicast Addresses and submit for publication as an RFC.
Jul 01   Resubmit the IPv6 Node Information Queries spec
Aug 01   Compete Address Selection specification and submit for Proposed Standard
Dec 01   Update ICMP document and resubmit for Draft Standard
Dec 01   Complete DNS Discovery draft and submit for Proposed Standard
Dec 01   Update Generic Tunneling specification and resubmit for Proposed Standard
Dec 01   Complete updates to Basic and Advanced API specifications and submit for Informational
Mar 02   Complete Scoped Address Architecture and submit for Proposed Standard
May 02   Submit document describing IPv6 renumbering model for Informational.
No Request For Comments

Current Meeting Report

IPv6 Working Group Minutes
Minneapolis IETF
March 18 & 21, 2002

Bob Hinden, Steve Deering, Margaret Wasserman

Minutes taken by Bob Hinden and Margaret Wasserman.



Introduction & Announcements, Steve Deering & Bob Hinden, 5 min.
Review Agenda, Steve Deering, 5 min.
Document Status, Bob Hinden, 10 min.
Moving IPv6 Documents to Draft Standard, Margaret Wasserman, 30 min.
Default Router Preferences and More-Specific Routes, Rich Draves, 15 min.
DNS Discovery Update, Dave Thaler, 15 min.
IPv6 Node Requirements, John Loughney, 10 min.
Minimum IPv6 Functionality for a Cellular Host, Hesham Soliman, 30 min.
Minimum Requirements of IPv6 for Low Cost Network Appliances, Atsushi Inoue, 10 min.
IPv6 Node Requirements follow up, John Loughney, 5 min.
Prefix Delegation Introduction, Steve Deering, 10 min.
Automatic Prefix Delegation Protocol for IPV6, Brian Haberman , 10 min.
DHCPv6 Prefix Delegation, Ralph Droms, 10 min.
IPv6 Router Advertisement Prefix Delegation Option, Nathan Lutchansky, 10 min.
Prefix Delegation Discussion, Steve Deering, 15 min.
IPv6 Flow Label Specification, Jarno Rajahalme, 45 min.
Reserving bits in RFC 2473 Interface IDs?, Erik Nordmark, 20 min.
Make IMEI-based universal IPv6 interface IDs a w.g. Draft?, Francis Dupont, 5 min.
Scoped Address Architecture Update, Tatuya Jinmei, 10 min.

Monday, March 18, 2002

Introduction & Announcements, Steve Deering & Bob Hinden

[Slides available at]

Steve Deering and Bob Hinden introduced the meeting. Announced that Margaret Wasserman is becoming a co-chair of the IPv6 working group. Effective immediately. Margaret has been involved in the IPv6 (a.k.a. IPng) working group since close to the beginning and will add valuable cycles to running and managing the working group. She will also be co-chairing the NGTrans working group.

Review Agenda, Steve Deering

Steve Deering reviewed the agenda. No changes.

Document Status, Bob Hinden

RFC's Published
- (none)

IESG Approved
- (none)

IETF Last Call completed
- Unicast-Prefix-based IPv6 Multicast Addresses (Proposed)
o In final stages of IESG approval (w/ MALLOC draft)

Discussion that current version of this draft does not cover link-local and has passed IESG review and is ready for approval.

"Host-based IPv6 Multicast Addresses Allocation"
covers link-local and should become a working group document to cover this case. Group agreed to make this a working group document.

- IPv6 Node Information Queries (Proposed)
o IESG wants applicability statement on usage

AD's wanted there to be an applicability statement on where/how this was to be used.

- RFC2372 IP Version 6 Addressing Architecture (Draft Standard)
o Waiting on resolution of Nordmark proposal for Reserving bits in the Interface ID

Submitted to the IESG
- Default Address Selection for IPv6 (Proposed)
o IETF Last Call underway
- A flexible method for managing the assignment of bits of an IPv6 address block
o Needs new draft based on IESG comments
- An analysis of IPv6 anycast (Info)
o In AD review
- Internet Control Message Protocol for IPv6 (Draft)
o AD Comments, needs new draft for IETF last call
- IPv6 3GPP Recommendations (Info)
o Just submitted to AD's a few days ago.

IPng Working Group Last Call Completed
- IPv6 Host to Router Load Sharing
o Combine with Default Router Preferences or keep separate?

Discussion that it is best to combine with Draves Default Router selection draft. Authors to meet and clarify remaining issues to result in single document.

- Basic Socket Interface Extensions for IPv6
o New Draft, Ready to submit to IESG?

Group agreed that this was ready to advance draft to the IESG.

ACTION: Document editor to submit "Basic Socket Interface Extensions for IPv6" to IESG for Informational.

- Advanced Sockets API for IPv6
o New Draft, Ready to submit to IESG?

Group agreed that this was ready to advance draft to the IESG.

ACTION: Document editor to submit "Advanced Sockets API for IPv6"
to IESG for Informational.

- Documents Ready for Working Group Last Call
o (none)

Moving IPv6 Documents to Draft Standard, Margaret Wasserman

[Slides available at]

Neighbor Discover

DAD Issue. Address Auto configuration will need to be updated.

RFC2374 will not go to draft standard.

RFC1886 DNS extensions

A6 approach will be moved to Experimental status.

Should we change to .int to .arpa
Would be good housekeeping to update.

Effort to update MIBs needs more people to work on.

Thaler: What would would be in an Neighbor Discover MIB? Some things covered in other MIBs.

Missing MLD from list.

Header compression can probably be taken on by RHC working group.

Recycle Privacy addresses should be recycled at proposed and is not ready to be advanced to Draft standard.

MIBs should be recycled to proposed. Not ready for Draft standard.

Conta: Thinks IPv6 working group should take on updating and advancing the documents that came from the ION w.g. Carpenter thinks the IPv6 over ATM is difficult and should be addressed.

Question was asked about advancing the documents the documents that are currently at Draft Standard to Standard. It would be good message to the community for this to happen. Thinks there are some potential user communities that are waiting for the IPv6 base spec to become reach Standard status.

Chairs and AD's don't think the IESG is ready to do this yet. There needs to be widespread deployment before this will happen.

Default Router Preferences and More-Specific Routes, Rich Draves

Internet Draft: <draft-ietf-ipv6-router-selection-01.txt>

[Slides available at]

Questions about probing routers that are currently unreachable. Why not just wait for hearing router advertisements? This may generate a lot of background traffic when there are many hosts talking to a few routers.

Question about how to set preferences. Draft has discussion who they should be set and relationship to preferences in other routers.

Need to clarify load sharing function as to which things it applies.

Next steps?

Wasserman: Why not just listen to a routing protocol. Response is that experience is that it is generally bad to have hosts participate in full routing.

Question about the requirements regarding load sharing. Draft will be clarified as to what is required. Draves will meet with Hinden to complete combining with load sharing draft.

DNS Discovery Update, Dave Thaler

Internet Draft: <draft-ietf-ipngwg-dns-discovery-04.txt>

[Slides available at]

Durand: Question about why is this site scope. Does this require sited boundary to extend into ISP? Would prefer the use of global addresses.

Huitema: If there was a prefix for this class of addresses this would be easier. Deering: Very reluctant to have a new set of scoping rules.

Margaret: Asked about need if there was DHCP. Deering replied that focus of this work is to allow discovery of a DNS server without DHCP.

Narten: Doesn't understand the requirements for this work. Requirements need to be defined.

Austin: Thinks this is another approach to adding configuration to DNS.

Response: No, Phase one is only about well known addresses to query DNS servers. This is specified in the draft.

Needs more discussion. No conclusions.

IPv6 Node Requirements, John Loughney

[Slides available at]

Announced the intent to from a team to write an IPv6 Node Requirements document. Contact John Loughney <> if interested.

Discussion if this is just list of RFC or scoping of when certain things should be used. Some thought that it should try to address both issues.

John will make a report on Thursday with the initial members of the team.

Minimum IPv6 Functionality for a Cellular Host, Hesham Soliman

Internet Draft: <draft-ietf-ipv6-cellular-host-00.txt>

[Slides available at]

Deering asked questions about other kinds of things that could be done that would break the assumptions being assumed in this draft. Answer is that this is the way that 3GPP defines the properties of the link.

Discussion about need for DAD. Suggestions to make sure environment is clarified and that if something different is done DAD will be required.

Need to do w.g. last call in April to meet 3GPP requirements.

Suggestion to target document to 3GPP instead of "cellular hosts". "Cellular" is too broad.

Overall conclusion that draft will need significant revision before it is ready but with focused work it should be able to be ready for 3GPP deadline.

Minimum Requirements of IPv6 for Low Cost Network Appliances, Atsushi Inoue

Internet Draft: <draft-okabe-ipv6-lcna-minreq-01.txt>

[Slides available at]

Deering said that the chairs would like to see if this work can be become part of the overall IPv6 Node Requirement document. Asked the authors if they could participate in the Node Requirements effort.

Discussion. Most people who came to speak agree that it would be better to do this. Also, there may not be too many differences from what other similar hosts need.

Thursday, March 21, 2002

IPv6 Node Requirements follow up, John Loughney

[Slides available at]

John presented progress of design team formation. No questions or comments.

Prefix Delegation Introduction, Steve Deering

[Slides available at]

Steve Deering presented concept of prefix delegation and an overview of the discussion at our last interim meeting in Redmond, Washington.

Thaler: Some discussion is needed about whether a dynamic routing protocol is being used between the provider edge router and the subscriber edge node. If dynamic routing is in place, it might not be necessary to provide any mechanism. Do we care about the case where dynamic routing is present? Or do we want to constrain ourselves to the case where dynamic routing is not present?

Decision held until after presentation of each mechanism.

Automatic Prefix Delegation Protocol for IPv6, Jim Martin

Internet Draft: <draft-haberman-ipngwg-auto-prefix-01.txt>

[Slides available at]

Soliman: Mechanism uses IPSec, how is that done? Martin: Admits that there is a bit of "hand waving" there. Question about how SAs are established, and what happens when the addresses used to establish the SA are delegated.

Huitema: Need for authentication between downstream router and delegator. When will the delegator say 'no'? Without authentication, opens up possibility for all sorts of attacks.

Martin: Wouldn't SA set-up address this issue?

Soliman: Not a global issue, ISP can supply tickets to subscribers.

Huitema: Mechanism is more complex than that, can be used to cascade networks.

Thaler: In most cases, this is actually easier.

When the link is established, the provider knows what organization is on the other end of the link.

Thaler: Trying to determine what the requirements are for a prefix delegation protocol. Is there a need to get prefixes from more than one delegator on the link? If not, then anycast might be preferable to subnet-local multicast. Martin: Issue with building SAs to anycast address, also issue for multicast addresses.

Need to specify behaviour when a request is made from the same requester, who has apparently forgotten that it has a request. Martin: Agreed that this should be specified.

DHCPv6 Prefix Delegation, Ralph Droms

Internet Draft: <draft-troan-dhcpv6-opt-prefix-delegation-00.txt>

[Slides available at]

Presented proposal for prefix delegation using a subset of DHCPv6.

Thaler: Prefixes may be reserved after advertisement and before the actual request/reply cycle happens.

Droms: Not really inherent in DHCPv6, may be carry-over from DHCPv4. Address is moved to bottom of the list, but isn't actually removed from the pool until request/reply is complete. Thaler: May be a problem in the case where several different prefixes are advertised to the same router. After the host chooses, it may discover that the prefix it requests is no longer available. Haberman proposal has the same problem.

Thaler: Issue is different. Haberman proposal only advertises whether some prefixes are available, doesn't specify a particular one.

Nordmark: Requests clarification about whether the proposal to use IPSec would replace current DHCPv6 authentication/security mechanism(s).

Droms: Yes, IPSec could be used to replace DHCPv6 mechanisms.

Other questions: Is site-local multicast used for these messages?

Droms: Yes. Assumes that there is no site border between these two routers?

Droms: Yes, but the line may be drawn so that the delegating router interface is in the customer site.

IPv6 Router Advertisement Prefix Delegation Option, Nathan Lutchansky

Internet Draft: <draft-lutchann-ipv6-delegate-option-00.txt>

[Slides available at]

Nathan Lutchansky was not present, so Steve Deering presented the draft.

Question: How will this work, given that routers don't process router advertisements?

Deering: The requesting router would have to process router advertisements to look for this option.

Huitema: Issue with the fact that prefix delegation is multicast. May be failure mode where multiple routers receive the same advertisement?

Deering: Intended for point-to-point link.

Huitema: Would prefer that prefix was explicitly assigned to a single node.

Perkins: Could we use a DAD-like mechanism for prefix delegation.

Droms: Haven't thought about this approach.

Huitema: Concerned about security. Thinks that we should never use a multicast response, because it can't be secure.

Deering: Spec allows a unicast RA in response to a RS. Huitema: Must be clarified.

Huitema: Do all proposals allow delegation of multiple prefixes?

Droms/Deering/Martin: Yes.

Prefix Delegation Discussion, Steve Deering

[Slides available at]

Nordmark: Do we understand the requirements for this area? Might be hard to choose without knowing the requirements -- security, multiple prefixes, how does it fit with other things, etc.? Haven't had that discussion.

Deering: That's right. But, urgency is coming from people who have an immediate need for deployment. Haven't considered the requirements for delegation of other information to the site. Nordmark: If protocol will be extensible link DHCP, may not be good to have too parallel mechanisms.

Dupont: Missed PPP extension proposal in list of proposals. Steve Deering added it to slides.

Dupont: Raised issue of site boundaries. Deering: Site borders go through nodes. Site borders can be in subscriber edge router, with link in ISP site. Or, in provider edge router, so link is in subscriber site. Or both, so that the link is small site unto itself.

Question: Would simplified DHCP server be in the provider edge router?

Droms: Could be visualized both ways.

Perkins: Re-raising the DAD-like stateless prefix delegation protocol. Didn't mean it as a subset of DHCP. Has it been considered?

Dave Thaler: Provider router has to be authoritative, so that it can install filters and/or static routes?

Commercial provider. Sees DHCP and Haberman/Martin proposal as basically the same, just differs in transport and message format. Needs some sort of prefix delegation protocol for deployment this year.

Nordmark: Does other information need to be provided? Yes. Emphasized need for other configuration information for applications. Would like everything to be the same (DHCP?).

Deering: Comments on his opinion of a DHCP solution. His normal reactions against DHCP don't apply in this scenario, since he sees this as a stateful situation.

Hinden: His opinion is that there should be only one solution. Deering: disagrees.

Wasserman: Thinks that we still need work to determine requirements.

Narten: Requirements should be written down, so that they can be reviewed by others not in the room.

Deering: Called the question about whether we are ready to pick a solution or start narrowing down the list. Mixed reaction.

Nordmark: Suggested that we might be able to move forward with an established proposal, like DHCPv6, for immediate needs and continue to explore other proposals.

Durand: Parts of these proposals are vague, such as hand waving about IPSec. Hard to decide anything until firmed up. Huitema: Agreed that we need to know security models before deciding on proposals.

Hain: Do we understand the requirement that we are trying to meet? He doesn't think so. Deering: Showed presentation slides and indicated what requirements are implied by the picture. Hain: We need words instead of pictures.

Deering: Given all doubts about possible range of applicability, security issues, etc. let's try to determine if there is consensus around eliminating some options and/or continuing work on some options.

There was a straw poll. Goal of this exercise is to re-do the straw poll now that more information has been applied.

Miyakawa: Japanese group has several documents that explain these requirements, but they are written in Japanese. Need to be translated into English. Volunteered to do this. Emphasized that open of the issues is the urgency. Needed to make IPv6 commercially realistic.

Consensus that there is enough sentiment against a new poll that it will be better to write requirements and take discussion to list.

IPv6 Flow Label Specification, Jarno Rajahalme

Internet Draft: <draft-ietf-ipv6-flow-label-00.txt>

[Slides available at]

Dupont: Conflict between the statement that the flow label should be included in signalling and the fact that flow label set-up may not be completed?

Rajahalme: If not known, a different flow label can bet set-up for each transport connection.

Carpenter: Although he is a co-author, he doesn't agree with the draft. Believes that we have to have another look at the granularity of what we mean by "flow" and the relationship of packets that share the same label. Thinks that the current specification over-restricts the concept of a flow.

Deering: Doesn't think that the document constrains the concept of a flow. Just says that, in the absence of other consideration, you assign a flow ID to each transport connection. But, could be used for other mechanisms.

Carpenter: Wants to run a few usage cases through the spec on a white board and figure out if that is true. May need text updates.

Meaning of zero flow label -- non-labeled flow? Rajahalme: Yes.

Continue to proceed with this work based on updated draft.

Reserving bits in RFC 2473 Interface IDs?, Erik Nordmark

[Slides available at]

Nordmark: Raised question in presentation of semantics in the U-bit.

Deering: Short history lesson on the genesis of the U-bit -- an explicit choice was made years ago (at the GSE/8+8 interim meeting and subsequent IETF meeting) to give the U-bit these semantics.

Nordmark: That choice was not documented well in the current specifications.

Narten: Disagrees with Deering -- not interesting to argue about whether the U-bit means that the address is globally unique or EUI-64. May not actually be globally unique.

Deering: Posted on mailing list that the U-bit means "could be considered globally unique". We couldn't establish a system that would make "more unique" global identifiers.

Narten: U-bit only indicates that the identifier is _supposed_ to be globally unique. Any mechanism that takes advantage of this will need to consider whether they are "unique enough".

Deering: Not just two choices -- drop U-bit semantics or add more semantics. Could keep U-bit semantics and not add additional semantics.

Nordmark: Yes.

Soliman: Useful to reserve, but needs to be discussed in context of possible use. May need discussion of when the reserved section of the ID space should be allocated. Nordmark: Now we're wandering into potential uses of the reserved space.

Dupont: We need to know the rules of the game. Wants to reserve the space now and discuss about further allocation later.

Huitema: A way to classify the addresses is extremely important. Could be used, for instance, to allocate a specific ID for a mobile DNS root.

Carpenter: Concerned about putting semantics in an ID field at all.

Narten: Reserving the bits does not add semantics. Other RFCs would need to be reviewed/approved to add actual semantics.

Hinden: There are costs to the v6 effort to reserving this bit. We need to revise several drafts, change shipping code, check implementations, etc.

Echoes Carpenter's concerns that putting semantics in this field is wrong.

Semantics in field are not good, but we are starting to see some advantages with applications that actually use the U-bit.

Deering: When done originally, it wasn't the intent to support multiple unique address spaces. Anyone can obtain address space from IEEE to put an EUI-64 in anything.

Thaler: This is not a Mobile IP-specific mechanism. He is in favor of reserving space. Started out not liking this until he understood the problem, but now he supports it.

Deering: Not sure what the requirements are. We may need a requirements statement first.

Consensus was not to reserve any space until we have agreement regarding the mechanisms that may use it. (Item 3B from the presentation).

Make IMEI-based universal IPv6 interface IDs a w.g. Draft?, Francis Dupont

Internet Draft: <draft-dupont-ipv6-imei-00.txt>

[Slides available at]

Deering: Do you think that the U-bit is going to be used? Will we develop applications that take advantage of the global uniqueness property? These identifiers could be used to generate unique IDs on the subnet, but what is the purpose of marking them as globally unique? Dupont: Thinks that we should show a "good image" outside. Don't change U/L bit again, because it was so hard to explain. Thinks that it was a mistake to do them, but we shouldn't change it now. Dupont: Does not think that there will ever be applications using the globally unique IDs. Deering: Then, why not just use U=0 for this purpose? Dupont: Some people think that we will eventually find a use for the globally unique bit. Doesn't seem to be consensus that this is useful.

Soliman: Why do we need this draft? Nothing is really wrong with it, but what does it buy us?

Hinden: Purpose is to provide globally unique ID space, right? Dupont: Yes. Hinden: Doesn't see the need for defining another globally unique ID space. Dupont: Do you have and EUI-64 in your phone? Hinden: No, but we could get them from IEEE. Dupont: But, the deployed devices don't have them. Hinden: We still need to add IPv6 devices to the phone, and we can add EUI-64s at the same time.

Soininen: May not want to make IMEI public, since this identifier is used to determine (for instance) whether a particular phone is stolen.

Probably don't want to send the IMEI out, since it can be used by someone to get your phone disabled.

If this ID is the basis for a protection mechanism for telephones, relying on security through obscurity, it would be imprudent to expose it without discussion with the standards bodies for phones.

No decision made on draft.

Scoped Address Architecture Update, Tatuya Jinmei

Internet Draft: <draft-ietf-ipngwg-scoping-arch-03.txt>

[Slides available at]

Hartrick: Since :: is in the scope "INADDR_ANY", we need a way to identify that in an address representation.

Deering: Document has been "cooking" for some time. Called the question about whether the spec is "almost ready" to be moved to PS. If we get resolution on the syntax for the zone IDs, how many people would be for initiating a WG last call at that point. Small consensus to issue a WG last call.

Supplemental Presentation On Eliminating Return Routability In Mobile IP, Erik Nordmark

[Slides available at]

Note: Presented because there was extra time at the end of the meeting.

Some clarification on why would want to eliminate RR. Reason is to avoid "bidding down" attacks.

Dupont: Asked about plans to advance Kempf's draft. Nordmark: No work has been done on that draft.

Thaler: Good to turn off Return Routability, because it has overhead.

Deering: What options are being considered for how to put a flag in the packet, other than putting it in the IID field. Nordmark: Advantage of putting it in the IP address is that if you spoof the IP Address you are no longer identified as the same node.

Huitema: We do not need to discuss alternatives. If someone spoofs your IP address, he can change all other bits in the packet. The one thing that he can't change is the IP address, so it has to be in the IP address.

Question: There are other alternatives, such as short-lived BSA.

Rajahalme: If you have secure ND, you will need to break into a secure router or switch to establish man in the middle attack. Nordmark: Yes.

Hinden: Securing ND would be quite useful. However, proposed use of this bit for Mobile IP is a concern. It requires that we change an existing technology to deploy a new technology.

Deering: We need to decide _now_ whether to reserve space or not, because the Address Architecture draft is done and ready to go to Draft Standard..

How many people would have to change their implementations to reserve these bits? (Several). Dave Thaler noted that the MS implementation would have to change, as it uses 63-bits for privacy addresses.

Consensus check indicated that there was no consensus to make this change.

Meeting Adjourned


Moving IPv6 Documents to Draft Standard
Default Router Preferences and More-Specific Routes in RAs
DNS Discovery Update
IPv6 Node Requirements
Minimum IPv6 Functionality for a Cellular Host
Minimum Requirement of IPv6 for Low Cost Network Appliance
IPv6 Node Requirements - Part 2
Automatic IPv6 Prefix Delegation
IPv6 Prefix Delegation Options for DHCPv6
Automatic Prefix Delegation Problem
IPv6 Flow Label Specification
Updates on IPv6 Scoped Address Architecture
Allocating bit in IID for Mobile IPv6
Reserving space in the Interface ID
IMEI based Interface IDs