Re: [v6ops] Planning for IETF #90

[Ray Hunter <[e-mail]>]

Fred Baker (fred) wrote:
> v6ops:
>
> Kitamura-san has posted draft-kitamura-ipv6-zoneid-free, and would like operational views on it. He has also requested agenda time at IETF 90. I suspect it may be more suited for 6man, but 6man isn’t meeting. Would you kindly take a look and comment?
>
> If there is operational interest, we can give him a slot.
>
> Fred
>
> On Jul 3, 2014, at 1:47 AM, Hiroshi Kitamura <[e-mail]> wrote:
>> Dear co-chairs of v6ops WG,
>>
>> We have submitted a I-D:
>>  "Free from Using Zone Identifier for IPv6 Link-Local Address"
>>  <draft-kitamura-ipv6-zoneid-free-03.txt>
>>
>> I quote the I-D Announce mail at the end of this mail.
>>
>> This idea "Zone-ID Free" is simple and harmless to the current system.
>> We think this idea helps many people who face problems on Zone-ID.
>>
>> So, could you give us a presentation time at 90th Toronto meeting, please?
>>
>>
>> - title and file name of the draft
>>
>>  "Free from Using Zone Identifier for IPv6 Link-Local Address"
>>  <draft-kitamura-ipv6-zoneid-free-03.txt>
>>
>> - speakers name and email
>>
>>  Hiroshi KITAMURA
>>  [e-mail]
>>
>> - how much time
>>
>>  10 min.
>>
>> Best Regards,
>> Hiroshi
>>
>>
>>> -----Original Message-----
>>> From: I-D-Announce [mailto:[e-mail]] On Behalf Of [e-mail]
>>> Sent: Wednesday, July 02, 2014 12:17 PM
>>> To: [e-mail]
>>> Subject: I-D Action: draft-kitamura-ipv6-zoneid-free-03.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>        Title           : Free from Using Zone Identifier for IPv6 Link-Local Address
>>>        Authors         : Hiroshi Kitamura
>>>                          Shingo Ata
>>>                          Masayuki Murata
>>> 	Filename        : draft-kitamura-ipv6-zoneid-free-03.txt
>>> 	Pages           : 17
>>> 	Date            : 2014-07-01
>>>
>>> Abstract:
>>>   This document describes "Zone-ID Free" functions that make end
>>>   users free from using zone identifiers (Zone-ID) for IPv6 link-
>>>   local addresses.
>>>
>>>   When users deal with IPv6 link-local addresses, it is thought that
>>>   it is mandatory thing to specify accompanied Zone-IDs. For end
>>>   users, however, it is troublesome and nuisance thing to do it.
>>>   Because it is very hard for normal end users to find appropriate
>>>   Zone-IDs for this purpose.
>>>
>>>   From another viewpoint, the usage of IPv6 link-local addresses
>>>   accompanied with Zone-IDs is quite different from the traditional
>>>   usage of global addresses. Therefore many problems related with
>>>   Zone-ID are caused and new specifications are required to fix these
>>>   problems.
>>>
>>>   This document explores and describes how "Zone-ID Free" functions
>>>   work and how end users are released from using Zone-IDs when they
>>>   deal with IPv6 link-local addresses.
>>>
>>>   The "Zone-ID Free" functions are upper compatible with the current
>>>   usages of dealing with IPv6 link-local addresses and harmless to
>>>   the existing communications.
>>>
>>>   In order to obtain appropriate Zone-ID information, a new
>>>   technology "Zone-ID Learning" that issues multiple probes is
>>>   introduced.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-kitamura-ipv6-zoneid-free/
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-kitamura-ipv6-zoneid-free-03
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: v6ops [mailto:[e-mail]] On Behalf Of Fred Baker (fred)
>>> Sent: Thursday, May 22, 2014 4:43 AM
>>> To: v6ops
>>> Subject: [v6ops] Planning for IETF #90
>>>
>>> IETF #90 is two months away, and we have about six weeks to get drafts updated or new drafts filed. This is a heads-up.
>>> My rule for putting drafts on the agenda is that they are file or updated since the last IETF meeting and have had supportive
>>> working group commentary on the list. Filing at the last instant generally doesn’t help with folks’ commentary - you want
>>> to give them some time to read and think. So, filing drafts or making updates in June is recommended.
>>>
>>> Current draft status:
>>>
>>> IESG:
>>>    Jan 12  draft-ietf-v6ops-enterprise-incremental-ipv6
>>>    Mar 10  draft-ietf-v6ops-nat64-experience
>>>    Apr  1  draft-ietf-v6ops-64share
>>>
>>> Exiting WGLC; on its way to IESG:
>>>    May 19  draft-ietf-v6ops-clatip
>>>
>>> Working Group Document updated since IETF:
>>>    Mar  6  draft-ietf-v6ops-design-choices
>>>    Mar 11  draft-ietf-v6ops-mobile-device-profile
>>>
>>> Individual Submission updated since IETF:
>>>    Mar  4  draft-cui-v6ops-lte-lw4over6
>>>    Apr  7  draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node
>>>
>>> Working Group Document NOT updated since IETF:
>>>    Nov 26  draft-ietf-v6ops-dhcpv6-slaac-problem
>>>    Dec  6  draft-ietf-v6ops-balanced-ipv6-security
>>>    Jan 13  draft-ietf-v6ops-ipv6-roaming-analysis
>>>    Feb  4  draft-ietf-v6ops-dc-ipv6
>>>    Feb 14  draft-ietf-v6ops-ula-usage-recommendations
>>>
>>> Individual Submission NOT updated since IETF:
>>>    Dec  3  draft-taylor-v6ops-fragdrop
>>>    Jan 11  draft-osamu-v6ops-ipv4-literal-in-url
>>>    Feb 13  draft-cui-v6ops-lte-lw4over6
>>>    Feb 14  draft-foo-v6ops-6rdmtu
>>>    Feb 14  draft-liu-v6ops-dhcpv6-slaac-guidance
>
I recognize the issues detailed in this draft and feel that it is well
written.

2 comments:

1) IMHO The security considerations are incomplete.

Zone-ID free operations appears to assume security equivalence and
operational equivalence between all interfaces on a device.

two cases come to mind for the probes created in Section 4.2.
i) ping6 <Link-Local_Address_B> on a node with an IPv6 interface to a
telco e.g. LTE may incur significant charges, especially when roaming
ii) users definitely don't want security equivalence in firewall nodes
or other devices that enforce network security zoning

2) quote "When receiving Link-Local packets, there are no difficulties.
Zone-ID (interface) is easily and naturally identified from interface
that is used by received packets."

The assumption is made that identifying the zone-ID of inbound traffic
is trivial (as it can be identified by the arrival interface)
IMHO That is very much implementation dependent whether the physical
arrival interface is preserved to upper layers.

Where is it defined that a node should enforce that the arrival
interface of a link-link packet is preserved (and replies should only be
sent on that same interface)?

Is there's a potential security / operational consideration in that a
link local source address could be spoofed from another interface, and
replies would be sent out via a different interface, violating the fact
that a link-local address should be local to a link?

Maybe it should be made clearer that ND probes (section 4.2) should only
be sent when initiating new outbound communication from this node, and
not when replying to inbound queries?

And also recommend that nodes should enforce tying a link-local source
address to a physical interface?

Thank you.

-- 
Regards,
RayH