All,
Attached are the minutes taken for the IPv6 WG meeting in
Paris. Please review and comment.Regards, Brian & Bob IPv6 WG co-chairs
Internet Protocol Version 6 WG (IPv6)
Tuesday, August 2 at 1400-1600
CHAIRS: Bob Hinden <[EMAIL PROTECTED]>
Brian Haberman <[EMAIL PROTECTED]>
------------------------------------------------------------------
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
<draft-pashby-ipv6-detecting-spoofing-00.txt>
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.
<draft-pashby-ipv6-network-discovery-00.txt>
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 <Foo>, 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.
----------------------------------------------------------------------
smime.p7s
Description: S/MIME cryptographic signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
