Skip to main content

Minutes for 6MAN at IETF-96
minutes-96-6man-1

Meeting Minutes IPv6 Maintenance (6man) WG
Date and time 2016-07-19 08:00
Title Minutes for 6MAN at IETF-96
State Active
Other versions plain text
Last updated 2016-08-30

minutes-96-6man-1
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