2.3.9 IP Version 6 Working Group (ipv6)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
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

Last Modified: 2004-09-09


Robert Hinden <bob.hinden@nokia.com>
Brian Haberman <brian@innovationslab.net>

Internet Area Director(s):

Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: ipv6@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/ipv6
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/ipv6/index.html

Description of Working Group:

The IPv6 working group is responsible for the specification and
standardization of the Internet Protocol version 6 (IPv6). IPv6 provides
a much larger global addresses space than its predecessor IPv4. This
enables global end-to-end communication and restores valuable properties
of the IP architecture that have been lost in the IPv4 Internet. The
IPv6 standards are widely implemented and are starting to see global

The IPv6 working group was originally chartered by the IESG as the IP
Next Generation (IPng) working group 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.

The primary focus of the IPv6 w.g. is to complete the standardization of
the IPv6 protocols, and to review and update the IPv6 specifications
based on implementation and deployment experience, and advancing them on
the standardization track as appropriate.

The working group's work items are as follows:

o Complete Prefix Delegation requirements and publish. Related
  remaining work is:
- Develop Proxy Neighbor Discovery solution for prefix delegation
  and publish. This enables a simple site border router to
  re-advertise downstream a prefix it hears on its upstream link.
o Complete revision of IPv6 MIBs (combined IPv4/IPv6 versions) and
o Complete "Default Router Preferences, More-Specific Routes, and "Load
  Sharing" and publish.
o Update to ICMPv6 (RFC2463) and publish.
o Complete "Node Information Queries" and publish.
o Update Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461)
  and publish.
o Investigate approaches to optimize or eliminate Duplicate Address
  Detection (DAD) to make reduce the delays incurred by DAD when there
  is a change of network attachment points. Publish a document defining
  DAD optimizations.
o Update "Privacy Extensions for Stateless Autoconfiguration" document
  (RFC3041) and publish.
o Complete work on IPv6 Node Requirements and publish.
o Complete work stemming from the working group decision to deprecate
  site-local addressing. This includes:
- Publish document deprecating the usage of Site-Local addressing.
- Publish revision of the IPv6 Address Architecture that includes
  the deprecation of site-local addressing.
- Publish a replacement for site-local addresses that removes the
  major limitations and allows for local allocations.
o Update the IPv6 Address Architecture to resolve the issues raised in
  the IAB response to the Robert Elz appeal and publish as a Draft
o Complete work on Scoped Addressing Architecture and publish.
o Update IPv6 over PPP (RFC2472) and publish.
o Complete work on "Link Scoped IPv6 Multicast Addresses" and publish.

All new work items not listed above require the approval of the working
group and IESG before they will be taken on by the working group.

Goals and Milestones:

Done  Submit A Flexible method to manage the assignment of bits of an IPv6 address block to the IESG for Informational.
Done  Submit Flow Label specification to IESG for Proposed Standard.
Done  Submit Prefix Delegation requirements and submit to IESG for Informational.
Done  Revise Aggregatable Unicast Addresses (RFC2374) to remove TLA/NLA/SLA terminology.
Done  Draft on Proxy RA solution for prefix delegation.
Done  Submit IPv6 Node Requirements to IESG for Informational.
Done  Submit Site-Local Deprecation document to IESG for Informational.
Done  Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard
Apr 04  Submit Link Scoped IPv6 Multicast Addresses to IESG for Proposed Standard
Apr 04  Submit IPv6 Scoped Addressing Architecture to IESG for Proposed Standard
Apr 04  Submit TCP MIB to IESG for Proposed Standard
Apr 04  Submit Site-Local Deprecation document to IESG for Informational
Apr 04  Submit Unique Local IPv6 Unicast Addresses to IESG for Proposed Standard
May 04  Submit update to ICMPv6 (RFC2463) to be republished at Draft Standard
May 04  Submit Router Preferences, More-Specific Routes, and Load Sharing to IESG for Proposed Standard
Jun 04  Resubmit Node Information Queries to IESG for Proposed Standard
Jun 04  Submit updates to Auto Configuration (RFC2462) and Neighbor Discovery (RFC2461) to be republished at Draft Standard
Jun 04  Submit Proxy ND to IESG for Informational
Jun 04  Submit update to IPv6 over PPP (RFC2472) to IESG for Draft Standard
Jun 04  Submit update to IPv6 Address Architecture to the IESG for Draft Standard
Aug 04  Submit Update to Privacy Extensions for Stateless Autoconfiguration document (RFC3041) to the IESG for Draft Standard
Dec 04  Submit document defining DAD optimizations to the IESG for Proposed Standard
Jan 05  Re-charter or close working group.


  • draft-ietf-ipngwg-icmp-v3-05.txt
  • draft-ietf-ipv6-router-selection-06.txt
  • draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt
  • draft-ietf-ipv6-host-load-sharing-03.txt
  • draft-ietf-ipv6-link-scoped-mcast-06.txt
  • draft-ietf-ipv6-node-requirements-11.txt
  • draft-ietf-ipv6-rfc2096-update-07.txt
  • draft-ietf-ipv6-rfc2012-update-06.txt
  • draft-ietf-ipv6-rfc2011-update-10.txt
  • draft-ietf-ipv6-rfc2013-update-04.txt
  • draft-ietf-ipv6-scoping-arch-02.txt
  • draft-ietf-ipv6-unique-local-addr-07.txt
  • draft-ietf-ipv6-inet-tunnel-mib-03.txt
  • draft-ietf-ipv6-rfc2462bis-06.txt
  • draft-ietf-ipv6-optimistic-dad-02.txt
  • draft-ietf-ipv6-over-ppp-v2-01.txt
  • draft-ietf-ipv6-ula-central-00.txt
  • draft-ietf-ipv6-2461bis-01.txt
  • draft-ietf-ipv6-privacy-addrs-v2-01.txt

    Request For Comments:

    RFC1883 PS Internet Protocol, Version 6 (IPv6) Specification
    RFC1884 PS IP Version 6 Addressing Architecture
    RFC1885 PS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    RFC1886 PS DNS Extensions to support IP version 6
    RFC1887 I An Architecture for IPv6 Unicast Address Allocation
    RFC1888 E OSI NSAPs and IPv6
    RFC1897 E IPv6 Testing Address Allocation
    RFC1970 PS Neighbor Discovery for IP Version 6 (IPv6)
    RFC1972 PS A Method for the Transmission of IPv6 Packets over Ethernet Networks
    RFC1981 PS Path MTU Discovery for IP version 6
    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
    RFC2373 PS IP Version 6 Addressing Architecture
    RFC2374 PS An IPv6 Aggregatable Global Unicast Address Format
    RFC2375 I IPv6 Multicast Address Assignments
    RFC2450 I Proposed TLA and NLA Assignment Rules
    RFC2452 PS IP Version 6 Management Information Base for the Transmission Control Protocol
    RFC2454 PS IP Version 6 Management Information Base for the User Datagram Protocol
    RFC2460 DS Internet Protocol, Version 6 (IPv6) Specification
    RFC2461 DS Neighbor Discovery for IP Version 6 (IPv6)
    RFC2462 DS IPv6 Stateless Address Autoconfiguration
    RFC2463 DS Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
    RFC2464 PS Transmission of IPv6 Packets over Ethernet Networks
    RFC2465 PS Management Information Base for IP Version 6: Textual Conventions and General Group
    RFC2466 PS Management Information Base for IP Version 6: ICMPv6 Group
    RFC2467 PS Transmission of IPv6 Packets over FDDI Networks
    RFC2470 PS Transmission of IPv6 Packets over Token Ring Networks
    RFC2471 E IPv6 Testing Address Allocation
    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
    RFC3019 PS IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol
    RFC3041 PS Privacy Extensions for Stateless Address Autoconfiguration in IPv6
    RFC3122 PS Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
    RFC3146 PS Transmission of IPv6 Packets over IEEE 1394 Networks
    RFC3178 I IPv6 multihoming support at site exit routers
    RFC3306 PS Unicast-Prefix-based IPv6 Multicast Addresses
    RFC3314 I Recommendations for IPv6 in 3GPP Standards
    RFC3316 I IPv6 for Some Second and Third Generation Cellular Hosts
    RFC3484 PS Default Address Selection for Internet Protocol version 6 (IPv6)
    RFC3493 I Basic Socket Interface Extensions for IPv6
    RFC3513 PS IP Version 6 Addressing Architecture
    RFC3531 I A Flexible Method for Managing the Assignment of Bites of an IPv6 Address Block
    RFC3542 I Advanced Sockets Application Program Interface (API) for IPv6
    RFC3587 I IPv6 Global Unicast Address Format
    RFC3697 Standard IPv6 Flow Label Specification
    RFC3769 I Requirements for IPv6 prefix delegation
    RFC3879 Standard Deprecating Site Local Addresses

    Current Meeting Report

    IP Version 6 WG (ipv6)

    Thursday, November 11 at 0900-1130



    Robert Hinden <bob.hinden@nokia.com>

    Brian Haberman <brian@innovationslab.net>


    - Agenda Bashing Haberman 04 Minutes

    dupont - requests time to speak about getting /16 prefix allocated for crypto generated id's.

    hinden - if we have time

    haberman - tahi interop test announcement - similar structure to previous tahi tests, some new things for ike, nemo, etc. more info at tahi web page.

    - Document Status Haberman 01 Minute


    no issues or comments on document status

    - Milestone Updates Hinden 10 Minutes


    chairs have worked with ADs to update charter milestones. the things-done list is bigger than the to-do list :).

    hope to get outstanding work done within next couple of ietf meetings.

    - Node Information Queries Hinden 10 Minutes

    - Goal: determine direction of the work

    last draft is -10, now shipping in several implementations. need to get this published. was consensus after vienna provided some clarifications on privacy addresses are made. plan was to make those changes and then submit as PS. is there anyone interested working on this? author hasn't been active lately.

    no questions/comments

    - Privacy Addresses v2 Krishnan 15 Minutes

    - Goal: Progress as Draft Standard

    - draft-ietf-ipv6-privacy-addrs-v2-01.txt

    what's new? - see slides

    hinden - agrees there are no interop issues, nor is the new algorithm better or worse, but the issues which caused the community to switch don't relate to this. there is no reason for implementors to change. the goal is not to get people to change code to comply with this. need to make this clear in doc.

    krishnan - has change pending that may require code changes

    hinden - well we can't do that, but let's discuss it when you present the change

    greg daley - we already understand well what well-distributed random numbers are. just need references to docs that explain that.

    krishnan - does have reference

    open issues

    - per-prefix knobs (will break backwards compatibility)

    ralph droms - how does it break backwards compatibility?

    author - not required in previous version of rfc3041

    thaler - don't make it a must, make it a may or a should and then it is a non-issue

    savola - this is connected to next issues regarding ULAs, so should discuss these together

    hain - this is no different to changing the default of generate or not. if you get per-prefix knobs, nodes that do that don't break older implementations. just means that older nodes are doing something different.

    nordmark - is there any possibility that the tie-breaker rules in RFC3848 has any interaction with this?

    hain - if you don't have one of these suffixes then tie-breaker won't take effect.

    thaler - longest-prefix match is last rule, so this comes in first. prefix doesn't matter until you've looked at every other rule there is.

    - isatap and rfc2526 downref

    thaler - don't have problem with new text. avoiding isatap addrs isn't really a MUST.

    - unique local addresses

    do they need temp addrs?

    daley - don't treat them differently, at least don't explicitly exclude

    hinden - yes, they're just unicast prefixes, don't treat them differently

    hain - agrees shouldn't consider them to be different, but there is a strong bias for operators to not want random values to show up in their internal network. so probably don't want to do this in the ULA case. per-prefix knobs solves this problem.

    carpenter - ULAs special? yes and no. in large company they're not special at all. outside that company those addrs are a bug. should be prefix specific and then ULA is just a special prefix.

    nordmark - agrees

    thaler - only concern about per-prefix knobs is that hosts won't know their prefix until they get RA, so how does host get configured?

    krishnan - it is configured on host, hasn't thought about how this is administered.

    savola - assume many enterprises will want to use ULAs for local communication only, but might still want to generate temp addrs for global communication. therefore recommend that by default ULAs don't generate temp addrs. but then you need normative ref to something that defines ULA.

    hinden - might be better to put text in ULA doc as this doc is going to DS.

    hain - are you considering lifetime support?

    krishnan - higher lifetime is bound to RA, but max for temp addr is independent of that.

    hain - per-prefix knobs might require per-prefix temp valid lifetime

    thaler - pleas make clear that prefix doesn't need to be subnet prefix but something shorter could be used

    hinden - that would work well for regular unicast addresses as well

    -02 version has been submitted, but hasn't been published yet. ULA text is in there.

    -64-bit IID only?

    will add clarifying text to say that IIDs don't have to be 64 bit, but this text only applies to 64-bit IIDs.

    Any other issues?

    droms - if there will be another rev and opportunity to comment, then he has new text that doesn't need to be discussed here

    krishnan - there will be another rev

    - IPv6 over PPP v2 Varada 10 Minutes

    - Goal: Progress as Draft Standard

    - draft-ietf-ipv6-over-ppp-v2-01.txt

    no changes since last -01 rev was released in June

    is in last call now

    one editorial change planned, unless further comments come in

    please review and make any comments on the mailing list soon.

    savola - i have provided feedback a couple of times, but has not gone anywhere other than author contacting me off list. what i see as problematic is that DAD can be disabled under certain circumstances, but doesn't say how implementations figure out whether these circumstances are met.

    haberman - will take action to talk to author to see what's going on with those comments.

    - AD feedback on 2462 update Jinmei 20 Minutes

    - Goal: Resolve AD comments

    - draft-ietf-ipv6-rfc2462bis-06.txt

    WGLC completed in July 2004, new rev -06 published in August

    submitted to IESG in Sept, AD review finished in Oct

    two major issues

    - M/O flag clarification

    - confusing wording regarding 'stateful' vs dhcpv6

    would like to confirm mailing list consensus in this meeting

    M/O flag behaviour

    - proposed resolution - describe details on flags in separate PS doc

    - (draft-daniel-ipv6-ra-mo-flags-01.txt, just adopted as WG work item)

    stateful vs dhcpv6

    - wording used as part of the 'O' flag, clarify why we use 'stateful' while RFC3736 calls it 'stateless', ugly but didn't want to introduce radical change - AD comment - it's just confusing

    proposed resolution - remove 'stateful' and just use dhcpv6 instead, should be ok if we agree with the previous change, RFC2462bis won't use the phrase of 'other stateful config' for the O flag. additional effects - 2461bis and M/O doc will need to be modified.

    nordmark - 2461 uses 'stateful' in 4 or 5 places. if we change name of O flag to 'other config' then we're fine. replace 'stateful' with dhcpv6 as appropriate in 2461bis.

    droms - agrees with nordmark.

    other minor issues

    - change on the 'A' flag

    what happens if value of A flag changes over time

    answer: nothing - should be pretty clear in section 5.5.3.

    droms - can't think of situation were previously advertised prefix becomes unavailable for autonomous auto-config, but just wants to be clear that this is being prohibited by this

    nordmark - prefixes should time out for SAAD. receiving a prefix means nothing. this needs to be clarified

    tatuya - this doesn't seem to be a substantial issue

    nordmark - if setting A flag off doesn't result in prefixes timing out for SAAD, then there is a problem, right?

    wasserman - if previously advertised prefix is re-advertised without A flag, then don't stop using previously configured address. but if lifetime times out, then you have to stop using the addr. needs clarifications for implementors.

    hain - agrees with margaret. during multi6 discussion there was some talk about prefixes in the RA used to determine whether this is the same link, so there might be a reason for RAs to turn up with A flag off (just to serve as link determinants).

    krishnan - thinks this is already clear from current text.

    daley - DNA is looking at link identification. link identification using prefixes might be a product of DNA design team. there may be some subtleties here. people may be relying on what they believe existing behaviour to be, so clarification may be useful here.

    tatuya - let's confirm consensus on mailing list, if changes are required then he will make them in next rev.

    other issues

    terminology ordering - alphabetical or 'as is'?

    wasserman - it's fine as it is

    need ref to addr-arch in LL conf - will do

    inconsistent wording regarding DAD section. just a wording issue - replace lowercase 'must' with 'should' to avoid possible confusion.

    next steps

    verify proposed resolutions to issues are OK. several positive responses and no negative ones on list. so WG agreeing on course of action.

    revised draft will be issued including further clarifications and changes and discussed above.

    snapshot is available at http://www.jinmei.org/draft-ietf-ipv6-rfc262bis-07beta1.txt

    hold it waiting for 2461bis? another AD comment

    proceed to IETF LC anyway?

    Daley - has this already completed WG LC?

    Tatuya - Yes. Initial AD review has also been done.

    Chairs - will send to IESG with 2461bis when that is ready.

    Router selection draft update - dave thaler

    draft -05 passed wg last call, submitted to IESG

    several editorial nits, and 2 technical ones

    draft-06 addresses all but 1 issue

    editorial nits are available on issues list for this draft

    all included in -06

    implicit deletion (issue from Thomas Narten)

    - delete all routes if router lifetime -> 0?

    - no, requires explicit deletion of each route, therefore no change in -06

    current behaviour is also consistent with Prefix Info Opts

    Narten - when I made comment, I had notion that default router that stops being router, doesn't make sense to forward traffic to it any more.

    nordmark - there might be a useful distinction between default router = send me packet and i'll send it off where i can, and being a good router for default...

    thaler - draft addresses this already, there is some discussion and an example or two

    thaler - interpreation of router lifetime is lifetime of presence of router in default router list

    some discussion between narten and thaler that went too fast for me to catch, but sounded like agreement :)

    last two issues are separate on issues list, but turn out to be the same issue

    24 dynamic routes (alex zinin), 27 end-to-end reachability (steve bellovin)

    zinin has submitted text

    savola - isn't this issue also in basic RA? are we trying to fix a specific case of a more generic problem here? is this the right place to fix this? maybe as this is a PS while ND is going for DS, but fixing it in ND might be more appropriate as that is where the problem is.

    thaler - that's true

    nordmark - redirects should take care of this. introducing more-specifics makes this more complex.

    thaler - having two on-link routers that don't co-operate can be made to work with this.

    wasserman - doesn't think this is reasonable text. agrees that routers dumping tables to hosts is obviously brain-dead, but this doesn't seem like it makes sense.

    thaler - clarifies

    wasserman - this still seems over-constrained. why MUST routers have this level of state complexity?

    thaler - zinin said that not doing route-damping in this scenrio is a 'recipe for disaster'

    savola - operationally this damping-feature is not called for. not typically implemented in IGPs. doesn't see the use here. does see the benefit of only advertising a prefix if link is up.

    nordmark - two routers on link that don't co-operate is a scenario where this doesn't help, so what are we really solving with this.

    arturo azcorra - involved in research project working on home-gateways. thinks home gateway will typically have capabilities for routing, security

    savola - what about damping?

    azcorra - don't know

    hinden - being a backup or master tied to state of uplink is well-understood concept and there is lots of experience about that. doesn't want to tie this to route-damping. if you're going to do this, make sure it's stable - a general statement would help here, but the proposed text is too prescriptive.

    pascal thubert - does MAY correspond to point 1 and point 2? point 2 explicity excludes some potentially useful functionality.

    krishnan - this only usefully applies to home gateways, so don't need damping

    savola - could be two home routers, then it might be useful. operational status of link only goes so far.

    thaler - this is the 'better than nothing' case. authors have no preference. sounds like there is rough consensus to keep the first sentence, change point1 to SHOULD and remove point2.

    no objections

    - Multi6 Update Nordmark 20 Minutes

    - Progress update

    WG is at:

    identify proposals for further development - recharter

    soliman - have there been any discussions about failure discovery and propagating that to the site

    nordmark - there is a draft that talks about how to detect working path. ipv6 transport protocols to give positive advice to L3 probes. also link-layer indicators. there isn't anything about routers telling hosts that prefixes aren't working.

    itojun - is the Design Team aware that the L3 shim is basically a host-based NAT?

    nordmark - there have been exchanges about this on the multi6 list. depends what you mean by NAT. this is 1:1 mapping across whole system, which is not what NAT does.

    hinden - clarification - so IPsec would work?

    nordmark - yes

    itojun - presentation at app area meeting is required because you have broken something at L3?

    nordmark - no, the issue is that if apps today are doing caching or referalls then they won't get benefit of the existence of multiple other locators. so apps need to switch to using FQDN or keep track of full list of IP locators - this is the message that apps area needs to hear.

    hinden - this is really cool stuff, good job. in last slide, this provides multihoming to small sites that would never run BGP. People who run BGP have a solution today. don't lose the benefits for small sites by focussing on large sites.

    nordmark - issue is middle-ground where providing some policy tweaks might reduce pressure for small sites to go to the BGP solution. is there something easy that can be done to widen applicability.

    savola - of course small v4 sites solution is to use NAT.

    huston - BGP is BGP. the issue about why do it this way as distinct from the way it is done with IPv4 is related to fundamental considerations about the scalability of BGP. BGP won't handle the load if multihoming for small sites gets popular.

    soliman - do you need this if you have mobileipv6?

    nordmark - interactions with mobility have to be considered.

    jason schiller - need a mechanism for doing multihoming for small orgs.

    hinden - does this have characteristic that people who deploy it get to be multihomed, or does it require other people to play ball too?

    nordmark - peers don't have to be multihomed, but have to implement protocol to produce multihoming benefits. has been suggested that for transition reasons a proxy might be a nice way to go, but that proxy turns out to have nat-like characteristics.

    bagnulo - need to upgrade both hosts to preserve established communications through outages, but there are other problems that are solved without needing to upgrade peers.

    nordmark - You're right. One can get multihoming benefits while the communication is established without requiring the peer to implement the protocol. But if you want the multihoming benefit for established connections, both ends need to implement the protocol.

    carpenter - full benefits needs both hosts to have code in their stacks, but there is no flag-day. deployment is 'creeping'. conscious choice not to solve mobility problem in multi6 - keen to keep these two problems orthogonal.

    pascal hubert - could this replace nemo or mip route optimisation? doesn't know, but both groups should keep track of what each other are doing going forward. route-projection concept may be useful for multi6 for example. lot of synergies to be gained, even if requirements are not shared.

    - Address Selection for multihoming Matsumoto 10 Minutes

    - Goal: Informational

    - draft-arifumi-multi6-sas-policy-dist-00.txt

    same slides as were presented to multi6 mtg yesterday.

    thaler - src and dst come from common prefix. RFC3484 rule number 7? says prefer longest-prefix match. don't see any other rule to override that, so you'd get the desired behaviour already. these examples don't seem to require this mechanism.

    hain - the issue is where end node is talking with someone *beyond* ISP B. these examples don't show that.

    droms - initial example also needs prefix C added to WGP-A network that has no more bits in common to prefixes A and B.

    thaler - right, but router selection draft also deals with this.

    droms - there are cases where the router selection draft isn't enough

    soliman - even if you construct a case where router selection draft isn't enough, it doesn't seem practical. please come back with a practical example.

    hain - case 2 is already a practical example.

    soliman - why isn't router selection sufficient

    hain - this is a different approach to the same problem that may be desirable in some circumstances

    thaler - agrees with hain that router selection can't help here.

    soliman - but if you configure routers correctly router selection does work

    hain - 'correctly' is a relative term, if you have two provider provisioned routers that you have no control over, they are configured according to each providers definition of 'correct', that may not be useful

    tatuya - be more specific about prefix C that causes the problem - this will help to clarify the problem and the need for the solution

    thaler - agrees this is a problem. not convinced this is the best way to solve it.

    hinden - chairs view is that this needs more consideration and discussion before there is any need for WG to consider what to do.

    - Anycast Analysis Chairs 10 Minutes

    - Goal: determine direction of the work

    - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt

    basic problem is that there are disagreements on content of document in IESG. chairs have discussed with ADs and asked them to return doc to WG so that issues can be addressed. will go into 'AD-is-watching' state.

    also have another anycast BCP document that is being considered for adoption by grow WG. this is dealing with IPv4 anycast BCP at the moment. input on IPv6 anycast is appreciated.

    savola - it is useful to clarify somewhere that the role of anycast in ipv6 specs may be slightly different than what people expect. but the issue is that now that we have this document on 'shared-unicast', what should the ipv6 wg be documenting? is it right to do this work here now given that scope might change significantly?

    lindquist - this might be better in the grow WG - it's not IPv6 specific - it's operational.

    haberman - need to decide this as a group - will have this discussion on the mailing list after people have had time to digest work of itojun, kurtis and new anycast mailing list.

    kitamura - is setting up anycast mailing list. issue is different from current situation with anycast. don't care if itojun's work goes to BCP in this WG or not - will start discussion anyway.

    hinden - another WG to focus on this may be a good idea

    lindquist - this is good work that needs to be done, wasn't trying to prevent it being done.


    Privacy Addresses v2
    IPv6 over PPP status
    AD feedback on rfc2462bis
    Router Selection Status
    Multi6 WG and DT status
    Source Address Selection Policy Distribution for Multihoming