Re: [netmod] Changes to IPv6 zone definition in draft-ietf-netmod-rfc6991-bis-15

[Jürgen Schönwälder <[e-mail]>]

On Mon, Apr 08, 2024 at 10:03:14AM +1200, Brian E Carpenter wrote:
> > 
> > > While I'm here, I looked at typedef ipv6-address {}. Two comments:
> > > 
> > > 1. "If the zone index is not present, the default zone of the device
> > > will be used."
> > > FYI, although RFC 4007 describes the default zone, it's optional. For
> > > example, there is no default zone on Linux; if you execute a socket call
> > > with a zero or null zone, it's a run-time error.
> > 
> > I am pretty optimistic that you can memset a sockaddr_in6 to zero and
> > then fill out the sin6_addr field and things will work.
> 
> I'm afraid not. If you call sendmsg() with a link-local destination and
> a zero sin6_scope_id, you get "[Errno 22] Invalid argument". If you call
> it with a non-existing positive value, you get "[Errno 101] Network is
> unreachable".
> 
> Tested on my Linux machine with the attached Python script. And I knew
> this anyway from testing with ping.

So for a global address, a sin6_scope_id set to 0 means the scope is
ignored but for a non-global address, a 0 is taken as something that
must resolve to an interface numbered 0 (which likely does not exist)?

So what do we do, simply remove the sentence that talks about a
default zone?

> > Perhaps the zero
> > is not what RFC 4007 calls the default zone, then we need to find
> > better wording. But then RFC 4007 also says:
> > 
> >      An implementation should also support the concept of a "default" zone
> >      for each scope.  And, when supported, the index value zero at each
> >      scope SHOULD be reserved to mean "use the default zone".
> 
> However, that "should" and "SHOULD" have not been implemented for Linux.

> > > 2. There seems to be a limited character set for the zone ID. RFC 4007
> > > doesn't restrict the character set; it just says "non-null strings".
> > > IMHO that's a bug, but if I want to name an interface
> > > *%!@#$^&()_-+=:;'"?\|}{}{/.><, it's allowed by the RFC. (The text
> > > doesn't even specify ASCII, and the remark about "conflict with the
> > > delimiter" is meaningless, if you think about parsing.)
> > 
> > > If you intend to limit the character set more than RFC 4007 does, that
> > > should be stated, and probably discussed on the 6man list.
> > 
> > Yes, the zone ID is underspecified, and we can't really fix that. What
> > we had did not allow forward slashes, although they are used by some
> > vendors. So we are trying to improve but whatever we do is debatable
> > since the zone ID is underspecified. (On Linux, I am pretty sure an
> > interface name does not even have to be ASCII or UTF-8. Whatever we
> > end up doing, we will likely assume UTF-8.)
> 
> OK, I understand that choice. Maybe you should say in the description
> that the zone ID is underspecified in the RFC?

I will make the zone match .+ and adapt text from the definition of
interface names (interfaces/name):

   If a system uses zone names that are not represented in UTF-8, then
   an implementation needs to use some mechanism to transform the
   local name into UTF-8. The definition of such a mechanism is
   outside the scope of this document.

> > This is why I suggested to write an ID that explains what happens if
> > people go creative with zone IDs so that people know that certain zone
> > IDs will not play nice with YANG modules, certain zone IDs will not play
> > nice with URLs and so on. People can than take an informed decision and
> > deal with the consequences.
> 
> Well, I think 6man really ought to clean up RFC 4007 in this respect.
> But that is a battle for another day.
> 
>     Brian

> import socket
> 
> def tryz(zone):
>     try:
>         print("Trying zone", zone)
>         sock = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
>         sock.connect(("fe80::2e3a:fdff:fea4:dde7", 12345, 0, zone))
>         result = sock.sendmsg([msg_bytes])
>         print("Result:", result, "bytes sent")
>         sock.close()
>     except Exception as e:
>         print(e)
> 
> msg_bytes = bytes(b"Test")
> 
> tryz(socket.if_nametoindex("wlp2s0"))
> tryz(99)
> tryz(0)

On Linux 6.1.0 (Debian 12.5), I get:

Trying zone 2
Result: 4 bytes sent
Trying zone 99
[Errno 101] Network is unreachable
Trying zone 0
[Errno 22] Invalid argument

On MacOS 14.4.1, I get:

Trying zone 4
Result: 4 bytes sent
Trying zone 99
[Errno 22] Invalid argument
Trying zone 0
[Errno 65] No route to host

Apparently, the behaviours of implementations vary...

/js

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany