Minutes for 6MAN working Group at IETF96 in Berlin Agenda: - Introduction and Document Status - Recommendation on Stable IPv6 Interface Identifiers - Recommendation on Non-Stable IPv6 Interface Identifiers - IPv6 to Internet Standard - Updating RFC 6890 - Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution - IPv6 Specification to Internet standard #1: Introduction and Documents status presentation of the agenda by the co-chairs 5 drafts in the WG 3 actif WG documents Fernado: waiting for update from coautors on 6106 #1: Recommendation on Stable IPv6 Interface Identifiers Clarified scope: - apply only stable IPv6 IID generation containing a link layer address - do not apply to cases where SLAAC is employed - s/link-layer address/stable link-layer address - - Changes: - - Next steps: - - Open mic: contributions made on section 6 of the document: #a: The RFC should specify all updated previous RFCs, and specify what precisely was updated. #b: All cases for IID generation should be specified #c: Also point to all previous related RFCs include a text to soecify in which case this should be used(sugested by Lorenzo) Decision: Remove or keep section 6 of the document ==> Yes after ham election. #2: Recommendation on Non - Stable IPv6 Interface Identifiers why: updates 4941 such that use of temporary-only addresses can be used comment: Be clear on what you are updating in 4941 and how it is done. comment: include comment: We need to fix 4941, it doesnt anything about not generating stable addresses Conclusion: discussions should continue on mailing-list #3: IPv6 to Internet Standard Discussions are going on, some selected comments follow: rfc2460bis - Inconsistent use of citations to updated text (e.g. nocitations of RFC6564, RFC7522) - Clarity in meaning of “processes” and “examines” - p.8 contradictory text to RFC7045, which says you can only - discard through configurable policy? - Should RH be added to “full implementation” list? - Should we add note about not fragmenting ND? - p.20 Is the 60 second rule commonly implemented? - Next Header value 59? (Not in RFC7045) - p.24 PMTUD “strongly recommended”. What about PLPMTUD? Comment: PMTUD should not be recomended. We should deleed PMTUD path. Comment: PMTUD should be kept, maybe we can fix PMTUD. Comment: say why it is discouraged - p.24 is fragmentation being “discouraged” strong enough? - p.26 is Section 8.2 consistent with the Hop Limit definition? rfc1981bis: - Again,consistencyofcitations - PLPMTUD mentioned in Section 1, but spirit of RFC4821 not carriedthrough rest of document - experience” of MPTUD? - Combined use of PMTUD and PLPMTUD? - Section 5 is implementation issues from node’s perspective; what about nodes on path? (e.g. RFC4890) - p.3 lacks text on why 1280MTU can be beneficial; should we add? - P.8 if mention ND here, should we cite RFC6980? - P.8 RH0 mentioned; should we keep RH text for Type 2/3? - Should we have a Transport Area review of Section 5.5? - p.13 Add note about EH insertion causing PTB to go to sender? rfc2491bis: - Again, inconsistent use of citations (RFC5952,...) - p.9/10 – do we add ULAs to replace/update site-local texthere? (RFC4913) Conclusion: No objection to removing - p.11 assumptions *are* now made about /64 boundary; add areference to RFC7421 (Why /64?) Conclusion: No objection - p.11 no mention of “temporary” addresses when discussingRFC4941 and RFC7217; should we add it? (including use ofonly temporary addresses) - Why have RFC7371 updates been backed out in -02 version?Are we sure we want to do that? - Should we add RFC5453 (reserved IPv6 IIDs), RFC6890 (IPv6Special-Purpose Address Registry) and RFC7346 (IPv6Multicast Address Scopes) in the IANA section? Makes sense to add. #5: IPv6 Specifications to Internet Standard
 Open Issues Changes since last IETF: - Updated 2460bis, 4291bis and 1981bis - Removed RFC4941 from the core set of specifications to advance - Initiated WGLC: May 30th -> June 13th - Issues tracked at: https://trac.tools.ietf.org/wg/6man/trac/report/1 agrement on text in page 9 Page 12: RFC2460bis Header injection
Revision 05: Comment: processed in EH should ne specified Comment: Yes for the 1st paragraph, 2nd should be deleted Comment: we should be clear on Comment: clearify 2nd or delete Comment: change 2nd paragraph to : specify clearly where the next header should go. Comment: Remove second paragraph(Tim) Page 13: Comment: We should update HbH options text Comment: #6: Updating RFC 6890 Why update? : definition of "global" has causedimplementation issues. Proposed changes: - change global to global reachable. Comment: this is addressing the same problem as 4773 Comment: glabally routable might be clear? Comment: ULAs are globally reachable, but they aren't just routed. Cmment: - #6: Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution Trying to resolve the problem of multihoming without transition mecs How to tell host whcih adddress to use?: using RAs