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

[Hiroshi Kitamura <[e-mail]>]

Dear Brian,

Thank you for your mails which you sent to me.
Let me answer your mails here ([e-mail]) 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:[e-mail]]
> Sent: Wednesday, October 23, 2013 12:50 PM
> To: [e-mail]
> 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)
> >