Subject: RE: I-D Action: draft-kitamura-ipv6-zoneid-free-01.txt

From: Hiroshi Kitamura <[email-masked]>
Date: Mon, 28 Oct 2013 10:43:06 +0000

Dear Brian,

Thank you for your mails which you sent to me.
Let me answer your mails here ([email-masked]), please.

> > Hi,
> >
> > Can you explain a real use case where an ordinary user needs to choose
> > a Zone ID? (One important aspect of the HOMENET WG is to ensure that
> > there is a local name service, which is very important for ordinary
> > users.)
> >

In my I-D:
  3.1. Why we need Zone-ID? . . . . . . . . . . . . . . . . . . . .  6
  3.2. Which actual process requires Zone-ID information? . . . . .  6
  3.4. How Zone-ID info. dealt with in the current implementations.  7

 describes real use cases and details of what happens.

On current Unix/Linux implementation:
 Followings types of commands (without "%<Zone-ID>") would NOT work.
 
      > ping6 <Link-Local_Address_A>
      > ping6 <Link-Local_Address_B>

      > ssh   <Link-Local_Address_A>
      > ssh   <Link-Local_Address_B>

 Above commands stop with error.

Only followings types of commands (with "%<Zone-ID>") work / are allowed to execute.

      > ping6 <Link-Local_Address_A>%<Zone-ID_X>
      > ping6 <Link-Local_Address_B>%<Zone-ID_Y>

      > ssh   <Link-Local_Address_A>%<Zone-ID_X>
      > ssh   <Link-Local_Address_B>%<Zone-ID_Y>

They require to ordinary users to accompany with "%<Zone-ID>" 

Proposing idea "Zone-ID Free" makes the following commands (without "%<Zone-ID>") possible to execute.

      > ping6 <Link-Local_Address_A>
      > ping6 <Link-Local_Address_B>

      > ssh   <Link-Local_Address_A>
      > ssh   <Link-Local_Address_B>

This environment must be happy for ordinary end users who do not have enough network knowledge.

> > I think Windows simply picks a default interface if you don't specify
> > a Zone ID **.

I understand.

A default interface idea is one of methods to achieve not to accompany with "%<Zone-ID>".

> I have confirmed on my home setup that Windows does not require a ZoneID even with two fully active IPv6 interfaces. It
> used the correct interface, since the ping succeeded, but that may just be luck.

As you say "may just be luck", a default interface idea will be not wise enough.

I think you have already noticed that the proposing idea "Zone-ID Free" is more wise, because appropriate interface is learned dynamically.

> >
> >>    In order to achieve "Zone-ID Free" function, we extend this
> >>    operation.  We will send multiple NS packets via available all
> >>    interfaces. And replied NA packet that is received via either of
> >>    interfaces that are used for transmitting the NS packets is waited
> >>    for. After a NA packet is received, corresponding neighbor cache
> >>    entry will be filled/updated.
> >
> > What happens if NA replies are received on more than one interface?

After multiple NAs are received, corresponding neighbor cache entries will be created (as normal ND implementation does).

The "Zone-ID Free" idea proposes to modify NS transmitting only.
It does NOT propose to modify NA receiving.

> > It isn't hard to imagine network setups where every link has a host
> > fe80::1.

I agree.
I think your question is very natural question.

For such a case (the same value addresses are located on different attached networks at same time), it is impossible to specify the correct destination without accompanying with "Zone-ID (interface)"
information.

At that situation, please accompany with "Zone-ID".

The "Zone-ID Free" idea is upper compatible with current method.
It does not deny using "Zone-ID".

In my I-D:
 2. Problem Analysis and Goals  . . . . . . . . . . . . . . . . . .  3

 I describe goals and targets as follows.

-----------------------------------
   Goals of this document are to make end users free from using Zone-
   ID and to provide environment that they do not require to accompany
   with %<Zone-ID> to their applications arguments.

   (Non-Targets: people who have enough technical knowledge of
   networks and do not feel any difficulties to accompany with %<Zone-
   ID> information are not target. Also, a network environment that is
   too complicated to deal with for normal end users is not target.)

-----------------------------------

I think this description will answer your question indirectly.

Thank you for your questions.

Regards,
Hiroshi

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, October 23, 2013 12:50 PM
> To: [email-masked]
> Subject: Re: I-D Action: draft-kitamura-ipv6-zoneid-free-01.txt
> 
> I have confirmed on my home setup that Windows does not require a ZoneID even with two fully active IPv6 interfaces. It
> used the correct interface, since the ping succeeded, but that may just be luck.
> 
> Ethernet adapter sixxs:
> 
>    Connection-specific DNS Suffix  . :
>    Description . . . . . . . . . . . : TAP-Win32 Adapter V9
>    Physical Address. . . . . . . . . : 00-FF-59-8D-39-E6
>    DHCP Enabled. . . . . . . . . . . : Yes
>    Autoconfiguration Enabled . . . . : Yes
>    IPv6 Address. . . . . . . . . . . : 2001:4428:200:12c::2(Preferred)
>    IPv6 Address. . . . . . . . . . . : 2a01:348:6:5d0::2(Preferred)
>    Link-local IPv6 Address . . . . . : fe80::81a3:c4d4:bcdc:4d35%17(Preferred)
>    Autoconfiguration IPv4 Address. . : 169.254.77.53(Preferred)
>    Subnet Mask . . . . . . . . . . . : 255.255.0.0
>    Default Gateway . . . . . . . . . : 2a01:348:6:5d0::1
>                                        2001:4428:200:12c::1
>    DHCPv6 IAID . . . . . . . . . . . : 604045145
>    DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-3B-A2-69-E8-03-9A-3C-67-7A
>    DNS Servers . . . . . . . . . . . : 2001:470:20::2
>    NetBIOS over Tcpip. . . . . . . . : Enabled
> 
> Wireless LAN adapter Wireless Network Connection:
> 
>    Connection-specific DNS Suffix  . : fritz.box
>    Description . . . . . . . . . . . : Intel(R) Centrino(R) Advanced-N 6230
>    Physical Address. . . . . . . . . : 88-53-2E-B9-56-22
>    DHCP Enabled. . . . . . . . . . . : Yes
>    Autoconfiguration Enabled . . . . : Yes
>    IPv6 Address. . . . . . . . . . . : 2406:e000:e00a:1:28cc:dc4c:9703:6781(Preferred)
>    Temporary IPv6 Address. . . . . . : 2406:e000:e00a:1:f801:34ac:ae07:da74(Preferred)
>    Link-local IPv6 Address . . . . . : fe80::28cc:dc4c:9703:6781%12(Preferred)
>    IPv4 Address. . . . . . . . . . . : 192.168.178.20(Preferred)
>    Subnet Mask . . . . . . . . . . . : 255.255.255.0
>    Lease Obtained. . . . . . . . . . : 23 October 2013 16:29:13
>    Lease Expires . . . . . . . . . . : 02 November 2013 16:29:13
>    Default Gateway . . . . . . . . . : fe80::be05:43ff:fe8e:ce39%12
>                                        192.168.178.1
>    DHCP Server . . . . . . . . . . . : 192.168.178.1
>    DHCPv6 IAID . . . . . . . . . . . : 310924078
>    DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-3B-A2-69-E8-03-9A-3C-67-7A
>    DNS Servers . . . . . . . . . . . : fd00::be05:43ff:fe8e:ce39
>                                        192.168.178.1
>    NetBIOS over Tcpip. . . . . . . . : Enabled
> 
> 
> C:\windows\system32>ping fe80::be05:43ff:fe8e:ce39
> 
> Pinging fe80::be05:43ff:fe8e:ce39 with 32 bytes of data:
> Reply from fe80::be05:43ff:fe8e:ce39: time=1ms Reply from fe80::be05:43ff:fe8e:ce39: time=1ms Reply from
> fe80::be05:43ff:fe8e:ce39: time=1ms Reply from fe80::be05:43ff:fe8e:ce39: time=1ms
> 
> Ping statistics for fe80::be05:43ff:fe8e:ce39:
>     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:
>     Minimum = 1ms, Maximum = 1ms, Average = 1ms
> 
> % this one is a loopback:
> 
> C:\windows\system32>ping fe80::81a3:c4d4:bcdc:4d35
> 
> Pinging fe80::81a3:c4d4:bcdc:4d35 with 32 bytes of data:
> Reply from fe80::81a3:c4d4:bcdc:4d35: time<1ms Reply from fe80::81a3:c4d4:bcdc:4d35: time<1ms Reply from
> fe80::81a3:c4d4:bcdc:4d35: time<1ms Reply from fe80::81a3:c4d4:bcdc:4d35: time<1ms
> 
> Ping statistics for fe80::81a3:c4d4:bcdc:4d35:
>     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:
>     Minimum = 0ms, Maximum = 0ms, Average = 0ms
> 
> Regards
>    Brian Carpenter
> 
> On 23/10/2013 14:23, Brian E Carpenter wrote:
> > Hi,
> >
> > Can you explain a real use case where an ordinary user needs to choose
> > a Zone ID? (One important aspect of the HOMENET WG is to ensure that
> > there is a local name service, which is very important for ordinary
> > users.)
> >
> > I think Windows simply picks a default interface if you don't specify
> > a Zone ID **.
> >
> >>    In order to achieve "Zone-ID Free" function, we extend this
> >>    operation.  We will send multiple NS packets via available all
> >>    interfaces. And replied NA packet that is received via either of
> >>    interfaces that are used for transmitting the NS packets is waited
> >>    for. After a NA packet is received, corresponding neighbor cache
> >>    entry will be filled/updated.
> >
> > What happens if NA replies are received on more than one interface?
> >
> > It isn't hard to imagine network setups where every link has a host
> > fe80::1.
> >
> >    Brian
> >
> > **
> > C:\windows\system32>ping fe80::1
> >
> > Pinging fe80::1 with 32 bytes of data:
> > Destination host unreachable.
> > Destination host unreachable.
> > Request timed out.
> > Request timed out.
> >
> > Ping statistics for fe80::1:
> >     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Oct 2013 21:24:41 +0900

On Mon, Oct 28, 2013 at 7:43 PM, Hiroshi Kitamura <[email-masked]>wrote:

> For such a case (the same value addresses are located on different
> attached networks at same time), it is impossible to specify the correct
> destination without accompanying with "Zone-ID (interface)"
> information.
>

So you're saying that we shouldn't use scope IDs, but if the same IPv6
address is on two links, then we must use scope IDs? How is the user
supposed to know whether to use the scope ID or not?

---

From: 神明達哉 <[email-masked]>
Date: Tue, 29 Oct 2013 20:09:08 -0700

At Mon, 28 Oct 2013 10:43:06 +0000,

> A default interface idea is one of methods to achieve not to accompany with "%<Zone-ID>".

<pedantic>
To be precise in this context, this should be a "default zone (ID)"
(and if we use a link-local address as an example, it should be a
"default link (ID)").
</pedantic>

Actually, RFC 4007 states the concept of default zone should be
implemented.  Maybe not many implementations follow that specification
(from a quick check at least FreeBSD supports the concept, although it
seems to be incomplete/buggy), but at least in terms of protocol
architecture we already gave this solution.

But in any case...

>  I describe goals and targets as follows.

When we discussed the scope architecture, I thought we had an agreed
sense that users who might ever want to use link-local addresses
directly are "people who have enough technical knowledge" and that when
they play with link-local addresses, they know what they are doing and
they'd rather be explicit ("I want to confirm that this particular
router via this interface/link is reachable").  A default zone might
still be useful as it's still deterministic, but I suspect such users
would certainly avoid some magic choice of zones under the hood.

For other types of scopes, the story might be slightly different, but
these scopes are not really used anyway (at least not in a way where zone
boundaries matter), and, in fact, all examples in this draft use
link-locals.  I'd even doubt people who don't have enough technical
knowledge ever want to use any IPv6 addresses directly, let alone
(narrower) scoped ones.

Either my memory in the original discussion is wrong or it's now more
common that non-technical people want to play with scoped IPv6
addresses.  But if it's the latter, I think this draft should first
explain who (except the authors:-) really wants that.  Otherwise it
would be difficult to convince others, especially those who share my
memory of the original discussion, on the need for this trick.

And, in any case, from a quick look, this draft basically only talks
about implementation techniques, not a protocol modification.  So, you
might rather bring it to developer communities first and see if the
idea is accepted.

--
JINMEI, Tatuya

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Oct 2013 09:00:15 -0400

Hi Tatuya,

> architecture we already gave this solution.

Yes.

> memory of the original discussion, on the need for this trick.

Having been deeply involved in those conversations, I agree with your
recollection of history.  Link-local addresses were not designed to be
used by everyday users.  I don't see the benefit of this draft.

Regards,
Brian