Current Meeting Report
Jabber Logs

2.3.6 IP Version 6 Working Group (ipv6)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional IPv6 Page
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 06/25/2002

Bob Hinden <>
S. Deering <>
Margaret Wasserman <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Bob Hinden <>
Mailing Lists:
General Discussion:
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.
  • - draft-ietf-ipngwg-icmp-name-lookups-09.txt
  • - draft-ietf-ipngwg-ipaddressassign-02.txt
  • - draft-ietf-ipngwg-rfc2292bis-07.txt
  • - draft-ietf-ipngwg-icmp-v3-02.txt
  • - draft-ietf-ipv6-default-addr-select-09.txt
  • - draft-ietf-ipngwg-addr-arch-v3-08.txt
  • - draft-ietf-ipngwg-scoping-arch-04.txt
  • - draft-ietf-ipngwg-rfc2553bis-06.txt
  • - draft-ietf-ipngwg-uni-based-mcast-03.txt
  • - draft-ietf-ipv6-dns-discovery-05.txt
  • - draft-ietf-ipv6-router-selection-02.txt
  • - draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt
  • - draft-ietf-ipv6-host-load-sharing-00.txt
  • - draft-ietf-ipv6-3gpp-recommend-02.txt
  • - draft-ietf-ipv6-flow-label-02.txt
  • - draft-ietf-ipv6-cellular-host-03.txt
  • - draft-ietf-ipv6-link-scoped-mcast-01.txt
  • - draft-ietf-ipv6-node-requirements-01.txt
  • - draft-ietf-ipv6-rfc2012-update-00.txt
  • - draft-ietf-ipv6-rfc2096-update-00.txt
  • - draft-ietf-ipv6-rfc2011-update-00.txt
  • - draft-ietf-ipv6-rfc2013-update-00.txt
  • - draft-ietf-ipv6-multilink-subnets-00.txt
  • - draft-ietf-ipv6-tunnel-v02-00.txt
  • - draft-ietf-ipv6-scope-api-00.txt
  • Request For Comments:
    RFC1885 PS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    RFC1883 PS Internet Protocol, Version 6 (IPv6) Specification
    RFC1886 PS DNS Extensions to support IP version 6
    RFC1884 PS IP Version 6 Addressing Architecture
    RFC1887 I An Architecture for IPv6 Unicast Address Allocation
    RFC1897 E IPv6 Testing Address Allocation
    RFC1981 PS Path MTU Discovery for IP version 6
    RFC1970 PS Neighbor Discovery for IP Version 6 (IPv6)
    RFC1972 PS A Method for the Transmission of IPv6 Packets over Ethernet Networks
    RFC1888 E OSI NSAPs and IPv6
    RFC2019 PS Transmission of IPv6 Packets Over FDDI
    RFC2023 PS IP Version 6 over PPP
    RFC2073 PS An IPv6 Provider-Based Unicast Address Format
    RFC2133 I Basic Socket Interface Extensions for IPv6
    RFC2147 PS TCP and UDP over IPv6 Jumbograms
    RFC2292 I Advanced Sockets API for IPv6
    RFC2375 I IPv6 Multicast Address Assignments
    RFC2373 PS IP Version 6 Addressing Architecture
    RFC2374 PS An IPv6 Aggregatable Global Unicast Address Format
    RFC2464 PS Transmission of IPv6 Packets over Ethernet Networks
    RFC2462 DS IPv6 Stateless Address Autoconfiguration
    RFC2463 DS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    RFC2461 DS Neighbor Discovery for IP Version 6 (IPv6)
    RFC2460 DS Internet Protocol, Version 6 (IPv6) Specification
    RFC2471 E IPv6 Testing Address Allocation
    RFC2450 I Proposed TLA and NLA Assignment Rules
    RFC2454 PS IP Version 6 Management Information Base for the User Datagram Protocol
    RFC2465 PS Management Information Base for IP Version 6: Textual Conventions and General Group
    RFC2452 PS IP Version 6 Management Information Base for the Transmission Control Protocol
    RFC2466 PS Management Information Base for IP Version 6: ICMPv6 Group
    RFC2470 PS Transmission of IPv6 Packets over Token Ring Networks
    RFC2467 PS Transmission of IPv6 Packets over FDDI Networks
    RFC2472 PS IP Version 6 over PPP
    RFC2473 PS Generic Packet Tunneling in IPv6 Specification
    RFC2497 PS Transmission of IPv6 Packets over ARCnet Networks
    RFC2507 PS IP Header Compression
    RFC2526 PS Reserved IPv6 Subnet Anycast Addresses
    RFC2529 PS Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
    RFC2553 I Basic Socket Interface Extensions for IPv6
    RFC2675 PS IPv6 Jumbograms
    RFC2710 PS Multicast Listener Discovery (MLD) for IPv6
    RFC2711 PS IPv6 Router Alert Option
    RFC2732 PS Format for Literal IPv6 Addresses in URL's
    RFC2874 PS DNS Extensions to Support IPv6 Address Aggregation and Renumbering
    RFC2894 PS Router Renumbering for IPv6
    RFC2928 I Initial IPv6 Sub-TLA ID Assignments
    RFC3041 PS Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    RFC3019 PS IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol
    RFC3122 PS Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
    RFC3178 I IPv6 multihoming support at site exit routers
    RFC3146 PS Transmission of IPv6 Packets over IEEE 1394 Networks

    Current Meeting Report

    IPv6 Working Group Minutes
    Atlanta IETF
    November 18 & 22,2002
    Bob Hinden <>
    Margaret Wasserman <>
    Slides can be found at
    Introduction and Agenda Bashing -- Bob Hinden (5 min)
    Document Status and Priorities -- Margaret Wasserman (5 min)
    Proposed Charter Update -- Margaret Wasserman (15 min)
    MIB Updates -- Margaret Wasserman (5 min)
    Prefix Delegation:
       Prefix Delegation Requirements -- Shin Miyakawa (15 min)
       DHCP Option for Prefix Delegation -- Ralph Droms (10 min)
    <draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt >
    Flow Label -- Jarno Rajahalme (20 min)
    Node Requirements -- John Loughney (30 min)
    Site-Local Usage / Scoped Address Architecture -- Bob Hinden & TBD (1-1/2 
    [Needs to be updated to indicate real speakers]
    DNS Resolver Autoconfiguration -- Alain Durand (10 min)
    Issues with DHCPv6 -- Ralph Droms (10 min)
    IPv6 over Fibre Channel -- Claudio DeSanti (10 min)
    Monday, November 18, 2002, 1930-2200
    [Notes taken by Bob Hinden and Margaret Wasserman]
    Introduction and Agenda Bashing -- Bob Hinden
    Bob Hinden reviewed agenda.  No changes.
    Document Status and Priorities -- Margaret Wasserman
    [Slides can be found at ]
    Proposed Charter Update -- Margaret Wasserman
    [Slides can be found at ]
    This is a proposed charter.  It has not been officially submitted to IESG 
    yet.  Opportunity for working group to comment.
    Urgent for Deployment
    Carpenter: Sympathetic to what try to do.  Have heard comment, why is the 
    IPv6 w.g. still meeting?  Thinks this is an important message.
    Kempf: Relationship to ND and Mobile IP?  What should be done with ND?  
    Should this be done in Mobile IP w.g.?  Is there interest in this in the 
    w.g.  Hinden: thinks IPv6 is responsible for this work and changes to ND 
    should be discussed in IPv6 w.g.
    Narten:  Mobile IPv6 document currently has changes to ND.  Doesn't think 
    changes are bad, but doesn't think changes are appropriate in Mobile IP.  
    Important that this be done as part of ND, not in Mobile.  Should be in 
    IPv6 w.g.
    Durand: There is a proposal 8:8 a long time ago.  Wishes the GSE 
    document has been published.  Would be useful for current 
    Droms: Thinks Link Scoped IPv6 multicast not being completed.  Has work 
    that depends on this.
    Perkins: Talks about ND advertisements.  Has had modifications to ND in 
    MIPv6 that have been there for a long time.  It is crucial that these 
    modifications be done.  Thinks MIP w.g. should be making these changes.  
    Doesn't think this would keep the v6 w.g. from making updates to ND 
    specification.  ....  Thinks it would be a mistake to not do this in MIP6 
    Bound: Is goal, conclude or hiatus.  A: Conclude.  Agree with Charlie P. 
    that ND changes should stay in MIP6.
    Hesham: What does point-to-point link bullet means.  Needs more 
    clarification if this is updates to existing document or new 
    A: Probably both.
    Hesham:  Multilink subnets?   A:  Not sure where this is going to be done.  
    No current plan.
    Narten:  If ML subnets is important, where will work be done, who is going to 
    do it, etc.  Needs problem statement.
    Itojun:  Status of anycast?  A:  Still in IESG, doesn't need to be listed as a 
    work item.
    XXX: What about IPv6 over different media?  A: Not in charter, but 
    proposals can be made.
    Thaler:  ML Subnet.  Is being discussed at zero router BOF tomorrow.  
    Currently an IPv6 w.g. document.  Thinks ML subnets covers RA proxy.  This is 
    close to being done if it is solving RA proxy.  More expanded solution 
    should be done elsewhere in IETF.
    Narten: "Flexible Method for Managing the Assignment of Bits of an IPv6" is 
    almost done.  Should be reviewed and submitted.  Need to check with 
    author.  No real work.  Should be finished.
    MIB Updates -- Margaret Wasserman
    [Slides can be found at ]
    ACTION:  Chairs to start working group last call on UDP MIB
    ACTION:  Chairs to start working group last call on IP Forwarding MIB
    Prefix Delegation
    Prefix Delegation Requirements -- Shin Miyakawa
    [Slides can be found at ]
    Nordmark: Are there any security requirements?  A: Doesn't think it is too 
    complex.  Are there any security issues for other environments, such as 
    cable modems.  Might want to be able to turn on security in some 
    environments (perhaps where there is more shared media).
    Dayley(sp?): This would be good for network mobility too.  Thinks really 
    need strong security for this mode.
    Will add security section.
    Should be ready for w.g. last call after new draft is published.
    DHCP Option for Prefix Delegation -- Ralph Droms
    <draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt >
    [Slides can be found at ]
    Wants to do last call end of the year in both IPv6 and DHC working 
    groups.  Interoperability testing by TAHI in January.
    Moore: Has a lot of issues with the notion of leases for addresses.  
    Thinks ISP's shouldn't be able to take addresses away.
    Nordmark:  Suggestion, might have default lifetimes in 
    specification that are weeks or months.  Could make lease the same a 
    contract with ISP.
    Hain:  Don't put operational policy in specification.
    Keith:  Understands need to keep in separate specification, but would like to 
    see a solution.
    Discussion between Moore and Droms......
    Nordmark:  It's not about mandating operational procedure, it is about 
    making suggestions for people to consider.  It is OK to say we think we 
    expect these to be long lived.
    Moore:  Important for applications to know about the expected 
    Flow Label -- Jarno Rajahalme
    [Slides can be found at ]
    Will issue a new draft.  Ready for IETF last call?
    Steve Blake:  Doesn't think that a destination can assign a flow label.  
    There will be conflicts that can't be resolved.  This at least needs to be 
    clarified in document.  Could be a new application try to connect to this 
    destination.  [Last bullet, slide 5]
    Bob proposed a much simpler flow label document, based on the appendix from 
    RFC 2460, but using the source, dest and flow label.  Has a first cut of a 
    much simpler document that he will send to the authors for 
    Jarno -- Concern that a simple implementation that only cared about three 
    values (no wildcards) might be too limited for some uses.  Needs for 
    wildcarding might result in storing more than one entry.  Doesn't think 
    that this WG should decide whether or not RSVP is useful and should be 
    enabled -- current draft defines how RSVP would work with the flow label 
    instead of the ports.
    Christian -- two comments.  (1) SDP is not a signally protocol, can't 
    achieve what is specified with SDP, because it only passes one address, not 
    two.  Can't have tuple of source/dest.  Jarno -- With this model, we could 
    just have "to this address, use this flow label", would wildcard the 
    source.  Christian -- not consistent with the rest of the model.  
    Doesn't think that an IPv6 specification should make assertions about how 
    the parameters should be used in other protocols.  Thinks we should say: (1) 
    flow=source, dest, flow id.  By definition, something with the same flow id 
    is the same flow.  (2) the flow id has no structure, mathematical or 
    Brian -- co-author of the document and he does agree with it with these 
    modifications.  Painfully hacked out to cut through a minefield of ideas 
    about how the flow label should be used.  But, also agrees with Bob 
    Hinden that we don't need this for the IPv6 flow label definition.  Could be a 
    page surrounded by I-D boiler plate.  We might be able to get 
    consensus on Bob's proposal, where we have failed to get consensus on this 
    longer document.  If we go to last call with this document, as 
    ammended, we may just go into another round of non-consensus.  So, his 
    tendency is to support Bob's approach.  Then, there is work to do after 
    that, which is to develop use-cases.  Jarno -- recalls a desire to add 
    default usage with transport connections and media streams.  Now in 
    section 4.  Sections 4 and 5 can be removed to get to what Bob 
    proposed.  If that is what is needed to get the basics through, then 
    that's what needs to be done.
    Hesham -- agrees very much with Bob.  The document is very wordy right now, 
    could be said in two paragraphs.  Should stay away from usage, just list 
    semantics and nothing more.
    Alex Conta -- Thinks that Jarno's presentation does a disservice to the 
    draft.  The presentation is longer than the draft.  Jarno did a lot of work 
    to explain the issues, but that gives the impression that the draft is long 
    and complex.  Thinks that if you try to address the issues that this draft is 
    a addressing, you can't make it shorter.  Jarno spent two slides on the 
    definition of the flow label, but it is only two paragraphs.  Concern 
    about counting number of pages.  This is the third version of the draft, and 
    we got here through several consensus stages.  The work today is the 
    result of suggestions, things said on the mailing list, including by Bob and 
    Margaret.  Trying to address all of those comments will get to the same 
    result.  The reason we are at this draft is that there were so many 
    issues with the appendix.  Doesn't know how taking that appendix and 
    massaging it will achieve consensus.
    Christian -- How do we proceed with usage cases?  It is a pitfall of this WG 
    that we do what other groups should be doing.  We should not be 
    defining a usage case for how this will work with RSVP, etc.
    Choy(?): Several groups are working on definitions concerning flows.  
    Wants this document to describe its objective.  Jarno -- already have this 
    definition in the document.  Doesn't include layer 2.
    John Loughney:  Thinks that the draft is not overly long.  Could find a 
    middle point between Bob's suggestion and the current draft.  Could 
    remove parts of the draft that specify what a flow label is, etc. and move 
    them to an appendix.
    Brian Zill -- Approach should be to take out "excess stuff" and keep 
    definition.  Remove signalling-related stuff and try to make the 
    document as simple as possible.
    James Kempf -- Thinks the draft is fine.  Lots of requirements are based on 
    some uses of the flow label.  Not related to the flow lable, per se, but 
    based on how other groups might use it.  Could move them out into a 
    separate document.
    Erik -- Two different things that we need to do:  (1) specify 
    semantics, and define what people are doing today, and (2) specify 
    constraints for how people can use them.  Document seems not to include 
    what you can do today.  Hard to extract from section 4 on 
    constraints.  Constraints are more focused on how to use it for 
    something new, not something you can do today.
    Bob will circulate what he has put together, at least to the authors.  Bob 
    doesn't want to be an author himself.
    Node Requirements -- John Loughney
    [Slides can be found at ]
    Thomas:  MAY on privacy extensions is too weak.  Should be a SHOULD if you 
    are the type of node to which it applies.
    Tony:  Shouldn't mention clients servers, etc., as this is too 
    Christian:  Agrees that we shouldn't talk about clients and servers, as 
    they are not part of the architecture.
    Tony:  If you want an address to be private, it can't be in the DNS.
    John L:  If you have suggestions, send them to the mailing list.
    Pekka:  Doesn't think that a detailed treatment of the use of privacy 
    addresses should be in this document.  Should be in next revision of the 
    Privacy Addresses document.
    John L:  This document shouldn't specify any new behaviour.
    Ed Maholic(?):  Isn't "SHOULD if you are concerned about it" the same as 
    MAY?  Thomas: No.
    Itojun:  Personally votes for MAY, in the interest of avoiding 
    duplicates.  Condition for need is defined in RFC 3041.
    Alain:  Back to issue of 3041 addresses in the DNS.  This is not the place to 
    talk about this.
    Elwin Davies:  Thinks that we need to say that some things must be 
    implemented, but must also include a knob to turn them off.  We did a lot of 
    that in IPv4 requirements.  Bob:  Not clear if that type of language 
    should go in here, or in an update to 3041.
    Brian: SL wording needs editorial work.  John L: Agrees.
    Christian:  On principle, the default address selection rules are the 
    default when you don't know better.  So, at best they could be a SHOULD.  
    John L:  Sounds reasonable. Rich:  Most of the rules in the default 
    address selection are SHOULDs, but some are MUSTs.
    John L:  Should we worry about IPv4? 
     Bob:  Doesn't know why we'd care, except for possible transition 
     Brian: First sentence reads like a joke, but it is a good one and we 
    should leave it in.  Some day, we may need to start an OGTrans WG 
    (old-generation) when IPv4 becomes a legacy protocol.
     Bob: Margaret should talk to v6ops chairs about whetherv6ops should do a 
    "transition requirements" document.
    John L:  Question on MIBs.  Are they a MUST or a SHOULD?
     Margaret:  Suggested SHOULD if you have an SNMP agent.  
     Brian: Disagrees with MUST support MIBs.  Agrees that you would only want to 
    do this if you have an SNMP agent.  
     Bob:  Do we want to define a minimal set of MIBs, or ignore this?  Does v4 
    host requirements say anything about MIBs.  
     Dave Thaler: Host requirements doesn't, router requirements does.
    Choy(?):  Title is node requirements, but seems to mix in functional and 
    operational requirements.  John L:  Doesn't include operational 
    requirements, etc., just what must be supported.  Choy:  Disagrees, 
    thinks that the document should define some functions, such as QoS.  John L:  
    QoS and functional requirements are far outside the scope of this 
    document.  An IPv6 can be anything from a super computer to a 
    temperature gauge.
    Bob:  Thinks we may want to list that you MUST not implement A6 
    records.  John L:  May be appropriate to list this in the appendix.  
    Alain:  Does not think MUST NOT is appropriate, as A6 is 
    experimental.  Erik:  If we point to the AAAA document, should point out new 
    Brian:  When 1122 was done, the BCP designation had not been invented.  
    Would BCP be more convenient than standards track?
    Bob:  Preference for BCP.  Over time, we'll change what we consider that 
    this is, rather than making it more and more firm.
    Thursday, November 21, 2002, 0900-1130
    [Notes taken by Sharon Chisholm.  Thanks, Sharon.]
    TAHI Test Introduction -- Hiroshi Miyata
    Site-Local Usage/Scoped Addressing (1-1/2 hours)
            Introduction:  Bob Hinden (5 min)
            Rich Draves (15 min)
            Brian Haberman (15 min)
            Rob Austein (10 min)
            Bob Hinden (15 min)
    DNS Resolver Autoconf -- Alain Durand (10 min)
    Issues with DHCPv6 -- Ralph Droms (10 min)
    IPv6 over Fibre Channel -- Claudio DeSanti (10 min)
    TAHI Interoperability Test Event
      Hiroshi Miyata
      Jan 20-24 2003, Makuhari Chiba Japan
    Test info
      Conformance and interoperability
    IPv6 site-local usage
      Bob Hinden
    Site-local status
      Address architecture defines format
      Address selection defines selection rules
      Work ongoing on
        Node requirements
        Scoped address architecture
    Issues in several areas
      - Site border router
      - Multi-site routers
        Site local in routing protocols?
      - Multi-site hosts
      - DNS
      - Applications
    Choices for IPv6 wg
      - Limited usage
          only used in disconnected sites
          no multi-site nodes
      - Moderate usage
          simple site-border router
          no multi-site host or router requirements
          two-faces/split DNS
      - Full usage
          require all nodes to be multi-site
          routing protocols aware of site boundaries
          multi-site DNS
    Moore: Let me just suggest we don't talk about compromises at this point. I 
    object to the direction the chair is trying to steer the group in.
    Site-local addresses
      Richard Draves
    Why do we have site-locals?
    How do they add complexity?
      Scoped addresses (link-local & site-local)
        Good features
      1. Simultaneous use of site-local & global addresses is allowed
      2. Multi-site host support is not required
      3. Routers required to support two modes
      4. We should document issues surrounding site-locals and their 
    What is a site?
      Administrative/ routing boundary
      Not geography
      Convex routing
        Paths between site-local source & destination stays within the site
    Architectural reasons
      Scoped addresses are natural expressions of network topology
        They are being retrofitted into ipv4
      Disconnected networks
        Global prefix not always available
        Intermittently connected networks with unstable global prefix
    [Crowd response about the wide deployment of this stuff]
    Security-related uses
      - Simple access control out of the box
      - Defence in depth because multiple routers between attackers and 
    victim will filter site locals
    Renumbering-related uses
      - Site-local connections preserved across renumbering events probably not 
    so useful because renumbering relatively ...
      - Site-local addresses in configuration files etc do not have to 
    changed when renumbering
          - For example, filters/ACLs based in site-locals do not change
    Network stack complexity
      - Meaning tcp/udp/ipv6
      - Very little additional complexity
         - Couple hundred lines of code, mostly in..
    Application complexity
      - Default address selection sufficient for many apps
      - Distributed apps that do referrals
      - Multi-sited hosts
        - getaddrinfo() returns site-locals w/ scope-id
        - Apps preserve scope-id info (use sockaddrs)
      - Two-faced DNS only current solution
      - draft-ietf-opngwg-site-prefix-05
      - Mark Andrews suggestion
          - Works with links-locals too
    Mobile ipv6
      - Can MN use a site-local home address?
      - MIPv6 could support using site-local home address to communicate with 
    Site-local correspondent back in home site while away from home
           - But not as currently specified
    Q - You made a suggestion that site local and link local are similar from 
    routing perspective, but I don't think that is true ....
    A - Certainly in the general case that is true.
    Q - To add site-local only a few lines?
    A - That is a host implementation
    Q - How much routing protocol support do we have in your stack?
    A - Static routes.
    Routing and forwarding of site local address
      Brian Haberman
    Target network 1
      - Broken up in two sites with dmv between
    Target network 2
      - Threw in another border to determine scaling issues
    Test platform
      - Original IPv6 stack
          - Software-based v6 router
          - RIPng
       - Zone id support in RIB/FIB
       - RIPng
       - Forwarding plane
           - Correct forwarding table lookup
           - Destination & source address checks
    Test scenario
       - Reachability tested with ping6
       - Throughput tested with ftp
       - FreeBSD workstations dumped route tables and snooped route 
    Observed results
      - From 10k feet, looks like VPN support
          - Differs with sharing the global prefix RIB/FIB
      - Performance hit in forwarding
      - Site specific FIB in hardware would help
    Random comments
      - This was routing/forwarding only
      - RIPng is fairly straightforward
      - Link-state will be more difficult
      - Site boundaries should not be arbitrary
        - IGP/EGP
        - OSPF area boundaries
    Random thoughts
      - Site-border routers can work
      - How often will a router have to support more than one or two sites?
      - Routing/forwarding is not the hardest part of site-local support
      - Not all routers would be multi-sited
         - Today's VPN boxes are a good model
    Q - Clarifying question. given that hardware stuff would be 
    beneficial with a few sites, what is the impact of deploying this on 
    existing networks?
    A - Today you would have to use an ACL (forwarding).  You could have a 
    route filter in BGP ... I've seen that done.
    Q - I'm wondering if the existing hardware will handle this?
    A - It will be hard to do because the routing protocol does not handle this
    Q - You said like vpn?
    A - You can consider a site like private network, with the site-local 
    tables like VPN tables.  But, share one global table.
    Q - Have we created scenarios where we have looked at the uses of 
    site-local and link-local and looked at how to make them work?
    A - No, we have not taken that approach ... we have a scoped address 
    architecture doc.
    Q - When a packet comes in on specific interface, how to look up?
    A - # of ways to choose what table you are in ... One way is to keep zone id 
    and use it to choose a table. Another way is to associate a linked list of 
    routing tables with zone id.
    Q - Same address on different interfaces?
    A - Zone id is the key.  The problem of carrying route-ids in the 
    routing protocol is that each router has its own idea of zone ids.  
    <General discussion of what a zone ID is...>
    Margaret - take this offline with Brian
    Q - Just want to point out there is a lot of legacy with VPN...
    Q - When you ran your tests, did you do any tests where you took links up 
    and down and looked at the reaction of the routing protocol
    A - Yes
    Q - How did having multiple zones affect convergence of the routing 
    A - It affected it, but not much
    Connected site-local considered harmful
      Rob Austein
    Scopes and borders
      Scopes (which imply borders)
        - node
        - link
        - site
        - global
      Things that change at borders
        - routing
        - security
        - naming
        - addressing
    Is single "site" border a good place to put a border for all of these 
    Application and scope
      - Some applications are intrinsically scoped (eg RA, ND)
      - Most applications have no concept of scope
      - Mmost applications have no way of expressing scope
      --> Stuff leaks across the borders
            - names leak (mail, web, files)
            - addresses leak (early name->address binding)
    One size does not fit all
      - Site borders sound at first like a nice simple approach
        ... but it's wrong
      - Are these the same border?
          - autoconfiguration system
          - address realm
          - two-faces DNS border
          - firewall
          - demarcation point
    Private addresses do not enhance security
      - Attacks via a border machine
      - Attacks via leakage
      - Weak ended node security sue to false sense of security
      - Firewalls have to filter bad global stuff anyway
         - Private addresses are just one more thing to filter
         - Private addresses do not make filtering easier
    Reachability versus ambiguity
      - Firewalls limit reachability
      - Private address realms also limit reachability
      - This is not an improvement
    Multiple sites
      - Devices that have to live in multiple sites are hard
          - multiple routing tables
          - multiple naming realms
          - multiple (potentially colliding) addressing realms
          - complex forwarding and leakage rules
    [Comment from presenter that Mark Andrew's proposal is the least evil way to 
    go down this horrible path]
      - If we have to keep site-local at all, only use in disconnected case
      - Globally unique address would be better in 
    What next?
      Bob Hinden
    [Admit that part of me likes global addresses like old internet 
    architecture, but then the other part of my brain looks at what people are 
    doing today, and people think that is how things should work.]
    My moderate proposal
      - Not an official chair position
      - Goal is to present a framework for what I think makes sense given the 
      - Pragmatically I think that people will create and use limited scope 
    addresses even if we say "no"
    Simple site-border router
      - Router with "no-site" interfaces
          - hard site-local filters build in for interface in "no-site" site
          - black hole route for FEC0::/10
      - Firewall at site border that enforces site boundary
      - Little or no impact on routing protocols, etc
      - No requirement for multi-site nodes
      - All routers include black hole route for FEC0::/10
      - Vendors may build multi-site nodes
      - Useful to document pitfalls of doing multi-site nodes
      - Keep site-local out of global DNS
      - Range of solutions possible
      - Two-face/split DNS
      - Mark Andrews' proposal
      - Ask dns-ext wg to take this work?
      - Issues with applications are real
      - However, site-local usage isn't worse than the world we are in today
      - Important that API's allow applications to override address 
    selection defaults
    Choices for IPv6 WG
      - My division
          - Limited usage
          - Moderate usage
          - Full usage
      - Other divisions?
    Margaret - (not chair view) site-local were invented for not-yet 
    connected networks.  Very useful for this purpose. I think we want to 
    retain this usage.  If we allow them to be used on connected networks we are 
    overloading.  Two different things should have two different concepts.
        Also is ambiguous scoped addressing the right way to solve the 
    problems we are trying to solve?  What we need is unique addressing ... 
    site local is not the way to solve all of this.
        Other thing -- in general, we are not going to be able to tell people to 
    not do local addressing, but we can try to give them a better way to do it. 
    We can say site-local is for disconnected and we have something better for 
    Q - Thank chairs .. I've gone from trying to get site-local to work well, to 
    restricting them to a disconnected is the right thing to do, now we may not 
    even want to do this. We want to think of the implications of allowing them 
    for disconnected sites, and consider getting rid of them.  
    Philosophically, think of model .. create boundaries ... then later as 
    network evolves, how to penetrate through boundaries, or start out within 
    the boundaries ... thinking about what happens when you open things up.
        Other thing, engineers try to go off and solve interesting problems ... 
    risk going forward, people will try to glue things together.
    A - I agree with some of that ... we may want use cases for gluing things 
    together ... VPNs ..
    Q - Two important issues not mentioned ... First one - leakage of dns 
    names If you know of a legendary black hole, it is causing big 
    problems, and site local will cause more problems.  Second problem -- 
    possible to use site-local for mobile ip when offsite, for mobile nodes it is 
    not possible to tell difference between local and not.  We need to be 
    A - Take mobile ip to that wg
    Q - Claim that site locals provide additional security is dubious at best.  
    Not clear how much it buys you.  If someone gets local traffic in your 
    network, you can't track it. You can't trust site locals because you can't 
    trust an address. The question is is the marginal security benefit worth 
    introducing complexity?  This will touch all network equipment, cause 
    operational problems... High cost for dubious benefit.
        I understand why people want it and why people think it makes sense . 
    I'd like to propose a different set of compromises.  If you buy the idea 
    that people are going to use them anyway, you basically need to provide 
    global addresses for your applications. Say use global addresses that you 
    are sure are going to only be local... this is dubious. Rhird option ... 
    deprecating.  It's easier to say don't use site-locals at all instead of 
    providing constraints that only provide minimal benefit.
    Q - Don't like site-locals.  We should look at history ... or history will 
    repeat itself. Last night in plenary people complain ... this is the same 
    stuff.  IPv4 address space before CIDR. people are not familiar with 
    multi-address.  If you put those two together ... people will want to use 
    Q - Answer Alain's comment.  There is an inherent bias to look at 
    anything new with suspicion.  The problem we have seen is that people have 
    not really wrapped their minds around the concept completely.
        People have said that site-local was only intended for 
    disconnected.  I don't agree this was the intent.  Certainly 
    link-locals and global addresses are mixed in IPv6 architecture today -- no 
    mapping expectation.  We have accepted the complexity.  If you take on the 
    IPv6 mentality of link and global, then site fits in nicely, even if it 
    didn't fit into the original IPv4 architecture.
        Also, Bob I like  your intermediate proposal.  To get people on the 
    fence, although I would not want to do anything to prevent the usage of 
    site-local in the overall schema.
    Q - I wanted to bring up a fact of operational network today. a typical ISP 
    operation is one single router that is their network on one side and 
    hundreds of customers on the other. Many hundreds of sites in one 
    router. This seems to be a difficult situation and should be kept in mind as 
    to how network are built today.
    Q - Hardware vendor.  Once this stuff is in hardware, I can't change it.  
    Didn't mention site-local in hardware ... I don't think I heard people 
    saying that they had too much experience with this stuff.
    A - We are not here to talk about address architecture
    Q - One slide item, you say that people who do global address, same as 
    scoped addresses, don't think this is true.  Filters don't allow 
    <something>, so you still have topology in the addresses ... need to 
    ensure accuracy in this discussion.
    Hain - scoped addresses exists in reality.  Can continue to meet people 
    where they are and provide a way to move forward, or we can try to fight it.  
    Most of arguments against them is that I don't understand things.  Best 
    current practice changes over time.
    Greg - My bias is new -- come to a decision.  I don't think this is the 
    site-local address solution.  Recognize need for stable addresses and 
    ability to deploy without having to change addresses.  If we look at IPv6 
    routing architecture, we moved to isp provided prefixes, because we don't 
    want routing tables too big.  What we need to do is keep that -- can't 
    change that.  We can allocate specific site-specific addresses that are not 
    routable. The principle problem is know that the address is not yours.  If we 
    can solve that problem then maybe site-local works.
    Bellovin - The original design is really bad. never defined a site. As for 
    buying security ... it doesn't.  We don't design for people only going out 
    through ALGs. Most nodes are going to have global addresses. The switch can 
    just reject what is not in its /48. Operational simplification. RFC 1918 
    made things complicated.  We could do this today and are not, so 
    probably won't happen in IPv6.
    Q - Local addresses are something everyone would like to have. First 
    point. Two issues. What to put into the document?  Second, what will 
    people implement. Document should constrain the experiments ... The 
    issues of dealing with site-locals are mainly transition cases.  People 
    then need to transition to global address space. We can put stuff in the 
    document, but it is not going to limit implementations.
    Christian - Lots of opinions ... We will come up with a compromise that 
    will be a "wink wink" compromise. Telling people to not use it will not 
    stop the usage.  If we want to stop usage then we need to provide an 
    alternative that people like better.  We should have compromise that is 
    rational, but we should work on the alternative. There is difference 
    between unreachability and ambiguity. You want unreachability. Problems 
    come from ambiguity.
    Q - We are at the point where we have to make a decision.  In 5 or 6 years 
    people will look back and hope we did things different.  If you don't 
    solve the problem in a good way, something else will take its place. NATs 
    require everyone to do things right, if not things stop working. IETF is 
    about a simple Internet where things work. Case earlier about 
    multi-sited nodes ... difficulty is that I see other cases where 
    multi-sites nodes will cause problems. If things don't work, it will be 
    difficult to debug. Is no worse than today.
    Q - In favour of site-local in moderate usage.  It is reality now and will be 
    used. I can see how it can be used. The reason that people NAT now will go 
    away. There might be applications where site-local addresses would be 
    useful, so support Bob's stuff. I don't think it will be that 
    Q - If we allow site locals it is rather dangerous.  If you decide to do 
    this, it will again delay deployment of new protocols.  If we do them, why 
    such as large address space?
    Hinden - The main thing I heard, if we chose a limited approach, we 
    should really go ahead and work on a real solution.
    <something off mike>
    Hinden - Not trivial ... Probably do go and work on something with 
    slightly better properties. Take things to a vote.
    Q - My comments is: Can you say what the tree options are and what they 
    Moore - problem with phrasing the question this way.  It glosses over the 
    layer 7 issues. I think this is the real problem.  plus two questions not 
    being asked.  Is there a consensus to accept site-local as 
    trustworthy?  Is there consensus that the WG should work on a real 
    Q - Quick comment ... also include address architecture changes?
    A - Approved for DS already.
    Q - In my opinion, these are not only choices.  Several people said even the 
    limited usage was evil.  Repair the problem gives those people a voice.
    Q - Clarify question:  Limited usage as currently defined?
    A - Yes
    Q - Trying to understand how questions will be asked...
    A - Which ones do you prefer? Which ones do you object do?
    Q - Rephrase ... None of the below and we define the real solution?
    Q - At some level this is a solution ... We should look at the problem.
    Margaret -- Is the problem statement to get global addresses 
    Q - We should also ask if people are comfortable to answer this or are 
    things to are too unclear.
    Margaret - Do people have enough info for us to ask the question?
    Consensus:  Yes, enough info
    Margaret - First round .. vote once for what you prefer.
      - remove entirely
      - limited usage
      - moderate usage
      - full usage
    No consensus:  ~30 Remove, ~51 Limited, ~57 Moderate, ~17 Full
    Christian - If you look at the result, it is clear that people don't like 
    site-local addresses.  The vast majority is somewhere between limited 
    usage and moderate usage.  Then we are close to the compromise.  People 
    know it is dirty -- then we go for the real solution.
    Margaret - It is difficult to limit something after the fact.  I don't 
    think the IETF should document something we don't think is right.
    Christian - People will be using it until we come up with a better 
    Q - Sense of room ... Really need to work on real solution.  Based on 
    numbers, think moderate approach.  Strong limitations and move towards a 
    real solution.
    Q - Think we can get consensus on limited usage and real solution.
    Q - Can we call the second question?
    Margaret - Time management question... Continue  or cut off to allow other 
    Consensus: continue
    Margaret - Vote for unacceptable solutions
      - remove entirely
      - limited usage
      - moderate usage
      - full usage
    Q - Confused.  Do we agree we should focus on either limited or 
    moderate usage.
    Consensus:  One of those two choices or somewhere in between.
    Margaret - I think we need to go off and create proposals for people to 
    look at with more details on which to base decisions.
    Margaret - The wg has agreed we don't want to remove them completely and 
    that we don't want to document them completely
    Q - Volunteer to document limited uses.
    Q - I think if we have a divided effort, we won't make progress.
    Q - We have had a million emails on this and I'd like to come to a 
    conclusion.  I think we are very close. simple. clear cut.
    Q - Simple question, hard answers
    Q - Before deciding all of this, in the discussions, there was some 
    interest in writing BCP for usefulness and non usefulness of 
    site-local.  This would be useful
    Margaret - I think we had some consensus on the list on this would be a 
    Good Thing
    Q - We have agreed without saying it, that enterprise has things that they 
    are trying to accomplish and will have to accomplish these regardless of 
    what we do.  Need to capture requirements.
    Margaret - Feel free to write a document.
    Q - <discussion of real solution> Requires 
    provider-independent address space.
    Moore - Agree with Tony on this point.  Don't want to get into this right 
    now though. I want to see if I understand the polling that has taken 
    place. I want to rephrase it slightly, it appears to me that we have near 
    consensus that it is OK to use site-local in disconnected networks. We also 
    have near-consensus that it may be OK to use site-locals in 
    restricted other uses. Like to see a vote.
    Q - We need another level of detail before we can get further 
    Margaret - We have made some important decisions today.
    Margaret - Brian has volunteered to document stuff we can't explore this 
    whole space in two minutes.
    Hinden - There needs to be some solution, otherwise there will be 
    Q - in the real solution, we need to flesh out the problem space.
    Q - people think the real solution is impossible, but there are two 
    drafts out there, look for "multi-six" on the internet draft page.
    Fred - like BCP idea. Willing to help, I would learn stuff and perhaps 
    provide benefit. I like the idea of limited usage.


    Requirements for IPv6 prefix delegation
    IPv6 Node Requirements
    DHCPv6 and other IPv6 docs
    Routing & Forwarding of Site Local Addresses
    Connected Site-Local Considered Harmful