IPv6 Working Group

Hain : People want to tell other people how to run their networks. Not IETF business. Keith Moore: IP tells people how to run their networks. People who misuse IP can cause harm.

Fred Templin gave remainder of presentation.

Tunnel MIB, Dave Thaler

Savola: have you thought about what kind of IANA registry you want to have? Dave: rules should be identical to what you need to do to get an iftype value (treat iftype the same as tunneltype).

Haberman: Should ipv6 adopt this document? Chairs call the question. No objection to making this a working group item.

ACTION: Next version of will be an IPv6 working group document.

Proxy RA, Dave Thaler

Itojun: You propose to add MTU option, what is the relationship with this modification and IPsec or SEND? Dave: If there are any security parts of the RA, they are stripped (unsecured RA), or we ignore it. It looks like a router that doesn't implement SEND to hosts.

Dave tends to agree with Brian Carpenter that this should become Informational, not PS. Any opinions?

Droms: Any interoperability issues? Or does this merely define how a device would implement this function. Dave: mainly the router. Trying to show that you can do this without NAT.

Huitema: what about spanning tree? Dave: Optional; don't always need loop prevention.

Dudley: Important to default (Spanning Tree) to on. For those links that have the requirements, should it be used as default. Dave: Yes.

Haberman: Any objection to adopting this document as a w.g. document for the ND proxy work item, as informational. No objections.

Adopt as a working group document? For Informational. No objections.

ACTION: Next version of will be an IPv6 working group document.

ICMPv6 Updates, Bob Hinden

Savola: Should we redo the w.g. last-call? Hinden: Yes, when new draft is out. Also, do we have to redo the implementation reports? Hinden: Need to look at that and check with the ADs.

Chown: Extra ICMPv6 type: Site Exit Routers suggested in multi6. Should we add that in this document? Hinden: Not sure we should do it now; it can use experimental types.

Haberman: Same issue with MLDv2 spec. Could have requested a code from IANA without any IETF action. Multi6 could go request a type on their own (at least until we change the IANA policy in this document).

Question: Who is the editor. Hinden: Currently I am, and we are working for new editor. If interested, please contact the chairs.

Wednesday, November 12, 2003

Router Selection, Dave Thaler

Savola: Don't use uppercase "may" in last guideline on slide 5. Thinks it is a misuse of terminology. Narten: Recommendations for operators or implementors. A: Operators. First three will be lower case, last will be upper case.

Neighbor Discovery Updates, Tatuya Jinmei

security/mobility issues raised
bug fixes, increase clarity
goal is another Draft Standard RFC
restrictions on new functionality Updates to RFC 2461 (Hesham primary editor)

1) mixed host/router behavior (on diff interfaces)
Proposal: state distinction is per interface

Templin: can you have a router with 1 interface? A: Yes

2) what if pref life > valid life?
Proposal: MUST NOT send

3) onlink assumption considered harmful
Proposal: remove this assumption

4) router lifetime values "inconsistencies". Does >18.2 hours violate spec?
Proposal: allow any value up to 65535, don't change sending behavior in section 6

5) clarify M/O flags in context of DHCPv6
Proposal: say stateful for M is RFC 3315 need similar reference for O

Greg Daley: dependency issues, O reference is just a draft

6) what happens if host receives prefix length > 64
Proposal: ignore and assume a 64-bit prefix? to be discussed on list

15) do we have to mandate link-local addresses as source in redirects? Proposal: yes, no change

7-9 are security issues Proposal: add a section on securing ND and refer to SEND for dynamic security

expand security considerations section based on send-psreq draft
add discussion on manual vs dynamic keying, currently vague

13) omission of prefix options considered harmful
Proposal: handle with ND extensions for movement detection not in this spec

14) introduce globally unique link id for movement detection
Proposal: handle with ND extensions not in this spec

10) relax requirements on RA frequency to allow 50ms
Proposal: allow, but not sure if safe

11) remove random delay in MNs before RS
Proposal: change 6.3.7 to allow no delay if know a hand-over (not startup, etc) has taken place

12) remove random delay in routers before RA
Proposal: draft-mkhalil-ipv6-fastra-*

Kempf: issues raised, may not want in this spec

Narten: legitimate for mobility but need to look at as part of the whole problem useful to talk about in DNA, wary of changing this spec.

Bound: Agree w/ Narten. Just pull these from the recycle issues and move forward.

Narten: put them on hold, don't adopt them at this point may adopt them later if get resolution when document is still open

Nordmark: #11 need to explain motivation for delay... power failure case clarifying intent may help the other discussion.

Kempf: talk to security AD on 7-9

Daley: interested in looking at issues in DNA but not committing

Huitema: don't add anything, have implementation experience with current draft and want to keep moving forward

Narten: don't make specific changes now

Itojun: limit to clarifications, don't introduce new stuff

15) remove delay before NS
Proposal: discuss

18) add R/H flags per MIPv6 spec
Proposal: accept

Mobility: Clarifications now, but not new features.
Limit effort to clarification..

Stateless Autoconfiguration Updates, Tatuya Jinmei

Some issues already have consensus on list others:

6) src addr selection issues: prefer link-local vs deprecated
Proposal: add reference to RFC 3484

7) deprecated addr handling, semantics of "new" communication consensus: incoming TCP connection is not "new"
Proposal: use text proposed on list
also talk about case where application specified deprecated address

8) semantics of L=0 A=1 case (addr configurable but not on link)
Proposal: no change

9) stable storage for auto-configured addr for stability
Proposal: mention it but not mandate

10) issues raised in send "use IPsec" is not enough
Proposal: add summary to security considerations, no change in protocol

11) DAD for 802.11
2462 says don't drop just because Llayer source != receiving node
802.11 doesn't meet this
Proposal: add note in Appendix A and reference draft-park-ipv6-dad-problem-wlan

Suggestion was made to have an IPv6-over-WiFi specification.

12) conflict with MLD spec re random delay for first packet
2462: if NS for DAD is 1st pkt, random delay
MLD report is usually the first packet
Proposal: just add a note? not a problem in _this_ spec

Dino: so don't send MLD reports for link-local addresses Daley: that would break things

13) DAD relayed issues: dad delay, random delay, how optimize dad
spec: SHOULD do DAD for every unicast addr
MAY skip DAD in some cases
should we remove the MAY?
Proposal: DAD optimization is a separate draft
need discussion on list

15) semantics of M/O
what requirement keyword, and specify DHCPv6?
Proposal: should mention DHCPv6, need to discuss details

16) whether a non-host router can use autoconf
a) configure a global addr
b) configure a link-local addr
c) configure itself about "other" information
Proposal: a=NO, b=YES, c=NO

Haberman: clarification - you mean per-interface definition right? Jinmei: yes

17) 'not-yet-ready' status of an autoconf addr for renumbering
can deprecated addr be used?
Proposal: out of scope of this update, specify as extension

18) avoiding intf failure on DAD failure
2462: SHOULD be disabled if no link-loc addr
Proposal: SHOULD but MAY allow automatic recovery

19) 2462 requires a 64-bit ID
same issue as 2461
no suggestion so far
Proposal: discuss on list

Itojun: is there an issues list page?
?: #13 what do you mean by "strict"
Jinmei: force DAD not DID
#18 MIPv6 suggested 3041 id in this case, should 2462 suggest A mechanism?
Hinden: need to be careful making changes
Huitema: #18 is really a security violation, bad guy can disable everyone's interfaces.

Chairs called question of making ND and Addr-Conf w.g. documents. No objections . Next version of drafts will be w.g. documents.

ACTION: Next versions of and will be IPv6 working group documents.

Scoped Address Arch Document, Tatuya Jinmei

Default zone ID value
draft suggests but does not require 0
issue: MIB needs 0
Proposal: SHOULD use zero

Thaler: why SHOULD and not MUST? (for MIB compliance)
Haberman: just make sure MIB and this doc agree
Itojun: can we get implementation reports and if no one uses non-zero then can use MUST

Alignment with draft-main-ipaddr-text-rep
Proposal: add a reference to the text-rep draft
normative or informative?

Haberman: make sure reference looks like the ref in the addr arch doc
(informative)

number of authors > 5

default zone ids for "subnet-local" multicast scope
Proposal: remove subnet-local, already removed from 3513 and addr-arch-v4

references ICMPv6 update as a normative reference
shouldn't be a problem (do concurrently)

Site-Local Deprecation Document, Christian Huitema

Huitema was called up to discuss, no slides

two main comments
1 (Pekka etc) more text about why NAT is bad, e.g. from Margaret SL-IMPACT Proposal: OK
2 recommendation for deprecation
current: existing behavior MUST be ignored by any new implementation
Q: what is a new implementation, is there a flag date, what if shipping both old and new versions, etc
one way: write weasel text
other way: replace MUST by SHOULD (Huitema prefers this)
rationale: writing more text doesn't help

Hinden: Thinks current text is just fine.

Carpenter: tends to agree with hinden, IETF doesn't have a clear procedure for versioning. No objection to SHOULD but like it with no changes. Leave it up to the implementor how to handle

Nordmark: may be helpful to add a sentence to state the intent?
Huitema: we already say that

Hinden consensus summary: Leave deprecation text as is and bring in two paragraphs from Margaret's document.

Haberman took consensus call: Any objection? No

ACTION: Chairs will advance when next version of draft is out.

Unique Local Addresses Document, Bob Hinden

Last call started Oct.22
Hinden is active author, Haberman is shepherding chair

Need for ULAs need to provide for local disconnected/intermittent allocation
Proposal: yes, better than other known alternatives

Huitema posted summary to the list of alternatives and problems with them

Application handling?
do applications need special knowledge about these addresses?
not introduced by this type of address, also applies to firewalls etc
useful to investigate general solutions to this class of problems
impact to source/destination addr selection?
will longest match rules just work?
provide more feedback via ICMP errors

Moore: agree don't burden address scheme with this
need to change address selection to get other things to work
it's hard enough to get address selection right, will probably have to change it anyway

Nordmark: ULAs are different than filtering etc, they're not reachable by design

Moore: by design they're not globally reachable, but it's a stretch to say they're not reachable by the peers of interest. Don't want applications to assume they're not reachable if not global

Nordmark: wrong impression is dangerous

Moore: hard enough to get right

Itojun: agree with Nordmark

Daley: this is a routing problem, why not just send destination unreachable Hinden: see later slide, discussed later in the talk.

Leakage Doc provides reasonable measures to prevent most leakage
Uniqueness minimizes impact
Leakage also affects firewalled addresses, etc
ULA is a good tradeoff among alternatives

Itojun: different types of filtering (e.g. don't advertise routes, do advertise and filter data, etc)

Charging, IANA instructions
IETF documents can't specify a specific charge or use of revenue
Proposal: remove 10 Euro and say low cost and intent to prevent hoarding
Geoff Huston (who raised issue) is okay with the new proposed text.

Filtering
black holing has bad side effects
Proposal: MAY respond with ICMP admin prohibit

Savola: is MAY strong enough?
Hinden: isn't ICMP always a MAY? should be consistent with other places
Savola: then change to SHOULD
Hinden: OK
Itojun: if we don't advertise then who will send admin prohibited
Thaler: diff subtypes for different filtering methods
Iljitsch van Beijnum: New ICMP message for source not right?
Haberman: scope exceeded does that
Iljitsch: is "scope" global here?
Moore: three cases
1) trying to send out to global internet
2) trying to send to a ULA with no route
3) filtering between two local networks
Carpenter: ICMP is likely to cross admin boundaries which may block ICMP not bad to define but can't rely on them arriving
Moore: can be defined and work most of the time

Alternative random algorithm Proposal: make sure others are allowed

Best name Proposal: take to list
Haberman: prefer really cool acronyms :)

Propose to make the changes discussed and advance?

Chown: language says need globally unique, but is probabilistically unique should be more clear

Haberman calls for consensus:

Any objection to proposed changes? No?
Submit to IESG with changes? Yes?

Moore: clarification - will revised document redo WG last call?
Haberman: we could have 1 week last call

Itojun: please ask whether we need another last call
Wasserman: yes

Iljitsch: locator/identifier separation work coming, not sure we should standardize something different
Hinden: Not advisable to wait
Narten: Right
Carpenter: sentence used to be there "might be useful for Multihoming too" make sure it's out. Hinden thinks it's already out.
Iljitsch: are they unroutable by design or by lack of a way to do it? so clarify.
Hinden: says "not routable with currently technology" or something
Kurt Lindqvist: don't wait
Wasserman: there's no conflict with locator/identifier work

ACTION: Chairs will start short working last call for when new draft is available.

Address Architecture Update, Bob Hinden

site-locals removed from special list of prefixes
added text describing SL deprecation
added instructions in IANA considerations to reserve and not reassign
changes dependent on approval of SL Deprecation document

changes due to IAB recommendations
2.5 nodes shouldn't make assumptions about address structure
2.5.1 nodes aren't required to validate that u=1 is unique

Identifier/Locator Separation, Kurt Lindqvist

Multi6 WG update

A number of proposal (6 active drafts, more expired) many/most split identifier (who) and locator (where) semantics and syntax vary for most, locators are todays IPv6 addresses

impact:

• We will not turn off ipv6 :-)
• All proposal will try to have no impact on ULPs
• Most involve a shim layer between ULPs and IP

• secure mapping of id<->locator
• goals are in RFC 3582
• more operational considerations being written (current drafts from Nordmark, crocker)

Meeting Adjourned