Internet Protocol Version 6 WG (IPv6)
Tuesday, August 2 at 1400-1600

CHAIRS: Bob Hinden 
        Brian Haberman 

------------------------------------------------------------------

1.  Document Status     (Haberman)
    Status on website:
    www.innovationslab.net/~brian/IETF63/IPv6/IPv6DocumentStatus.html 

------------------------------------------------------------------

2.  Call for Implementation Reports     (Haberman)
    Chairs request submissions of implementation reports for
        - Privacy Extensions for Stateless Address Autoconfiguration in IPv6
        - IPv6 over PPP

    Implementation reports needed before specifications can be
    advanced to Draft Standard.

    RFC2472 update reports should include IPv6CP, Interface ID
    negotiation, and stateless autoconfig (over PPP).  

    RFC3041 to DS reports should include lifetime management and DAD
    on temporary addresses.

    Chairs will send out report templates to mailing list.

------------------------------------------------------------------

3.  IPv6 Node Information Queries     (Haberman)
    Goal: Close open issues
    draft-ietf-ipngwg-icmp-name-lookups-12.txt


    Node Information Queries: completed WG last call, some comments received.
    Intended to document what has been implemented, put as Experimental .

    Current use does not conform to RFC3307 regarding multicast prefix 

    The other open issue is restricting answering of queries to
    All-Hosts or All-Routers addresses  

    Pekka Savola: restricting queries is important if the hosts answer
    pings to those addresses.  Comment the issue wasn't specific to
    this ICMPv6 message.
 
    Asked if anyone disagreed with changing the prefix to conform to
    RFC3307?  Means existing implementations have to change and
    impact on current deployment.

    Haberman: people asking for the change are switch vendors who want
    to see it as local use multicast address  

    Bob Hinden: prefer keeping it as is since fairly widely deployed 

    Elwyn Davies: originally agreed with Bob, but can hit cases where
    nodes respond who weren't addressed ... interference with other
    multicast groups  

    Jinmei: as an implementor, doesn't mind changing

    Poll to change Multicast address.  About equal.  Chairs will take
    issue to the mailing list.

------------------------------------------------------------------

4.  IPv6 Address Allocation to End Sites     (Narten)
    Goal: Discussion
    draft-narten-ipv6-3177bis-48boundary-00.txt

    /64 is a fairly hard boundary.  Some RIRs want to allocate /56
    rather than /48s.   Consensus to make this a working group
    document. There is no consensus that this will be approved. 
    Brian Carpenter says IAB should be told that this WG is thinking
    about changing an IAB document. Some would rather they didn't know.

    Wide ranging discussion on the political aspects of the RIR
    boundaries, /64 boundaries, and the intentions behind changing the
    boundaries. 

    Reviewed history.  Today, sense that it is time to revisit/revise
    current policies based on experience gained since 1998  

    The /64 boundary is architectural.  Very costly to change, but
    space to left of 64 is policy managed.  The /48 is a policy
    boundary. 

    Current RIR IPv6 policy: HD ratio of .8 used measures utilization,
    /48 to end sites, RIRs making large (/19) allocations to ISPs.

    How much space do we really have?  Should plan for space for 100
    years?  In 2050, /48 per person means 1/128 of space used.  Is
    this too much?

    Changing from liberal rules to conservative rules later has
    downsides, like we did in IPv4.

    ARIN proposed raising HD ratio to .94 .  May see a proposal to
    change /48 to /56 for SOHO at Oct 26 ARIN meeting.  Other RIRs
    also discussing   

    RFC3177 recommendations - A6 no longer in favor, GSE hooks
    superceded by multi6/shim6  

    RIRs view 3177 as IETF position on /48, would welcome IETF comment
    that /56 causes no architectural issues  

    ipv6-addr-arch-v4 states no boundaries other than 64 bit IID.
    Discussions about whether to go to /56 is in RIRs not in IETF  

    Document needs to document all relevant technical issues with /56
    vs /48  

    Alain Durand: did the WG make the wrong decision about /64
    boundary?  Should make sure future specs don't hard code 64
    assumption.  Thomas Narten: for things like CGA, more bits has
    technical value.

    Tony Hain: original policy was based on measuring hosts, whereas
    it should be networks so good to revisit.

    Thomas Narten: easiest is to just change HD ratio.  Discussion is
    on possibly doing /56 or not.  Changing /64 is off the table. 

    Tony Hain: Need to make sure 3177bis makes it clear that /64 to
    home is bad.

    Ralph Droms: what is impact of HD ratio change on operators?  does
    renumbering solve the problem?   

    Geoff Huston: .94 matches what we think is reasonable engineering
    ratio.

    Jim Bound: should accept as WG item 

    Jonne Soinenen: it's not just IETF docs that reference /64 but
    other communities like 3GPP, so it's very much fixed. 

    Ron Desorta: there's a consortium of RIRs which has a mailing list
    for this purpose, so that's the one place for the discussion (not 5-6) 

    Keith Moore: thinks it's a bad idea to change /48 recommendation.
    There are places that embed a /48 assumption, like 6to4. Thomas
    Narten: then the doc should talk about them.

    Keith Moore: disagrees that the doc should say the policy warrants
    revisiting.  Thomas Narten: doc does not recommend a change.  It's
    just to document the issues.  

    Poll taken to see if there is a consensus to adopt as a working
    group document.  There was a consensus is to adopt.

    Brian Carpenter: would be good for current IAB to comment, since
    RFC3177 is an IAB document.

------------------------------------------------------------------

5.  URI Syntax     (Fenner)
    Goal: Make decision to adopt proposal
    draft-fenner-literal-zone-01.txt

    Summarized the issues relating to how to represent scope in
    literal IPv6 addresses in URIs.  It's different from the site
    local issue since there's a specific grammar that makes it
    explicit there's a scope id  

    Doesn't want to use _ (underline) but not %.   Still need to
    choose replacement for _  

    Want to either move forward with this type of syntax with limited
    utility or else abandon the work.

    Greg Daley: might this be compatible with non URL use?   Bill
    Fenner: possible future path to accept this format outside URLs
    but not currently  

    Brian Haberman: Supports working on this, not worth effort to
    change the other spec.

    Keith Moore: should never use in production use in real
    applications, but fine with the doc.  Should have a statement
    saying use only for testing.  

    Bill Fenner: willing to accept document as working group item.  No
    objections.  Document adopted.

------------------------------------------------------------------

6.  M and O Flags of IPv6 Router Advertisement     (Park)
    Goal: Resolve open issues with draft
    draft-ietf-ipv6-ra-mo-flags-01.txt

    Draft defines host configuration behavior is for RFC3315 (DHCPv6)
    and information configuration behavior is for RFC3736 (stateless
    DHCPv6) 

    Requirements:
      1) Ability to indicate to host that DHCP is not available.
      2) Ability to get all DHCP config with a single message exchange.
      3) Ability to do DHCP without having to configure routers.

    Hesham Soliman and Dave Thaler: why is the third one a
    requirement?  

    Ted Lemon: get rid of acronyms HCB and ICB.

    Ralph Droms: should not use RFC numbers since they're overloaded.

    Ted Lemon: what if a rogue router sends RAs to deny service.
    Greg Daley: covered by the SEND RFC  

    Jinmei Tatyua: not recommending requirements just listing what
    have heard so far.  It's there to get around misconfigured
    routers.

    Hesham Soliman: tries to be too intelligent, everything else is
    configured in the router anyway (prefix etc)  

    Brian Haberman: only situation we need to handle here is just if
    no prefix option.

    Bob Hinden: thinks only the first one is actually a requirement.
    Second one is an internal DHCP issue.  

    Jim Bound: not a lot of DHCPv6 clients out there, so not super
    painful to change something.  But lots of implementations of M
    and O so hard to mess with.  

    Iljitsch: are there any implementations that do something
    different with M or O?  

    Discussion will be continued on mailing list.

------------------------------------------------------------------

7.  IPv6 over IEEE802.16     (Kim)
    Goal: New draft, Initial Discussion
    draft-jin-ipv6-over-ieee802.16-00.txt

    Service expected to be active within 1-2 years.  WMAN technology,
    uses standard IEEE MAC address.

    Transmission doesn't use MAC addresses, just 16 bit connection id
    since resources are scarce.

    L2 signaling protocol allocates CIDs to MAC pairs by a base
    station.

    Request folks to read draft and comment.  Not yet asking to become
    a WG doc, currently an individual document.  Authors encouraged to
    continue work and refine content and applicability. 

------------------------------------------------------------------

8.  Network discovery and spoofing detection     (Pashby)
    Goal:  Introduction to drafts
    

    Presentation outlines several deployment issues with IPv6 in
    U.S. Navy test networks.  Drafts outline problems and puts forth
    straw man proposal for addressing.  Meant more to kick start
    discussion of the issues. 

    Proposed list of changes to ND 

    Send NAs to solicited node mcast addr, discard others, same for
    redirects.

    Christian Huitema: why not just do SEND instead? 

    Francis Dupont: do we need a huge change just to address spoofing? 

    Jim Bound: some countries are not comfortable with CGAs until IPR
    issues resolved  

    Erik Nordmark: how does Ron's proposed change help? 

    Brian Haberman: IDS's could detect spoofing since they can get the
    packets too.

    Erik Nordmark: could just changing the multicast MAC address then.

    

    Purpose is to discover all IPv6 addresses on a network.  Propose
    echo requests to a multicast address responded to after random wait.

    Encourage people to read docs and comment on list.  

    Chairs request discussion of the issues on the mailing list.

------------------------------------------------------------------
 
9.  Distributing Default Address Selection Policy using DHCPv6 (Fujisaki)
    Goal:  Discussion
    draft-fujisaki-dhc-addr-select-opt-00.txt

    Proposal for using DHCPv6 to distribute Address selection policy. 
    Issues raised with the validity of using DHCPv6 to do the work.
    Multi-homing and interface vs. node based policy identified as
    issues. 

    DHCPv6 option for policy table used in RFC 3484 (address selection
    rules). 

    http://www.nttv6.net/dass/ talks about policy table
    implementations. 

    Dave Thaler: has problems with multihomed hosts, since this is a
    global table.

    Keith Moore: right, plus third parties are often naive and can
    cause problems.

    Ralph Droms: is it good to have control over this table is one
    question, whereas is DHCP the right way to configure is a
    different question.

    Ted Lemon: too hard to answer how to deal with multiple interfaces.

    Tatuya Jinmei: 3484 talks about app control over selection.

    Little support for this work.

------------------------------------------------------------------

10. Next Steps for IPv6 w.g.     (Hinden)  
    Advancing core specification to Standard
    Goal: Discussion

    Since 1994 we have published 61 RFCs!  Core protocols went to
    Draft Standard in 1998.  Working group scheduled to close end of
    this year.

    Chairs recommend that the core protocols go to Full Standard and
    already meet the requirements as specified in RFC 2026.

    Proposed list of core protocols: 
       IPv6, Address Architecture, ICMPv6, Neighbor Discovery,
       Stateless Autoconfuration , and Path MTU Discovery.

    Possibly also Privacy Extensions, IPv6 over , and DNS.

    Chairs propose to not reopen Draft Standard RFCs, just recycle as is. 

    Some of the protocols are in the RFC-editors queue now, IESG could
    just approve as Full Standard  

    Proposal is similar to NEWTRK proposals to reduce steps in the
    standards process  

    Margaret Wasserman: in favor of this proposal.

    Keith Moore: thinks it doesn't qualified as Proposed Standard,
    since we haven't figured out to handle renumbering, or multiple
    addresses for a host.

    Margaret Wasserman: there were no problems when moving to Draft
    Standard.

    Keith Moore: recommend we should identify what the missing pieces
    are. 

    Tony Li: we didn't solve those for IPv4, so should move RFC 791
    (IPv4 specification) to Experimental. 

    Ted Lemon: agree.

    List of RFCs to advance doesn't include APIs since those are
    Informational   

    Thomas Narten: would like to see fairly substantial deployment and
    usage.  Can we document production deployment or just testing? 

    Greg Daley: we're now seeing same attacks over IPv6 as we do over
    IPv4, so it's clearly production!

    Greg Daley: just let queued docs go to Draft without holding them
    up. 

    Greg Daley question to Keith: is pointing shim6 sufficient?  

    Pekka Savola: Address arch isn't mature enough to advance yet, due to
    recent changes.

    Margaret Wasserman:  DNS is a draft standard.  Wants to move it
    forward as well.

    Chairs will put together concrete proposal and send to mailing
    list.  

----------------------------------------------------------------------