Subject: Re: [v6ops] Planning for IETF #90

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 3 Jul 2014 14:21:32 +0000

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 <[email-masked]> 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
>  [email-masked]
> 
> - how much time
> 
>  10 min.
> 
> Best Regards,
> Hiroshi
> 
> 
>> -----Original Message-----
>> From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
>> Sent: Wednesday, July 02, 2014 12:17 PM
>> To: [email-masked]
>> 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:[email-masked]] 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
>

---

From: 神明達哉 <[email-masked]>
Date: Thu, 3 Jul 2014 09:33:44 -0700

At Thu, 3 Jul 2014 14:21:32 +0000,
> If there is operational interest, we can give him a slot.

FWIW, there was a discussion at 6man on a previous version of the
draft: http://www.ietf.org/mail-archive/web/ipv6/current/msg19286.html

I gave my own comments in that thread.  I've not read the 03 version,
and in any case I wouldn't be able to make a useful comment on whether
it has operational interest as I'm not a professional operator.

--
JINMEI, Tatuya

---

From: Ray Hunter <[email-masked]>
Date: Fri, 04 Jul 2014 07:43:29 +0200

>>>    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

---

From: Alejandro Acosta <[email-masked]>
Date: Mon, 07 Jul 2014 07:57:33 -0430

Hi There,
  I believe in somehow this should have operational interest.
  As the abstract describes zone-id can confuse and cause problems to
the end-user.

Alejandro,

El 7/3/2014 9:51 AM, Fred Baker (fred) escribió:
> 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?
> 
>> We have submitted a I-D: "Free from Using Zone Identifier for
>> IPv6 Link-Local Address" 
>> 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.
>> 
>> Hiroshi KITAMURA [email-masked]
>> 
>> - how much time
>> 
>> 10 min.
>> 
>> Best Regards, Hiroshi
>> 
>> 
>>> -----Original Message----- From: I-D-Announce
>>> [mailto:[email-masked]] On Behalf Of
>>> [email-masked] Sent: Wednesday, July 02, 2014 12:17
>>> PM To: [email-masked] Subject: I-D Action:
>>> draft-kitamura-ipv6-zoneid-free-03.txt
>>> 
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
There's also a htmlized version available at:
>>> -----Original Message----- From: v6ops
>>> [mailto:[email-masked]] 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
>> 
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>