[IPv6] Feedback on draft-evan-amateur-radio-ipv6

Fernando Gont <fgont@si6networks.com> Thu, 16 March 2023 05:59 UTC

Message-ID: <62dac15f-cbbd-e02d-61c8-e7211182d28c@si6networks.com>
Date: Thu, 16 Mar 2023 02:59:32 -0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1
Content-Language: en-US
To: draft-evan-amateur-radio-ipv6@ietf.org
Cc: "6man@ietf.org" <6man@ietf.org>
From: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/jaa3PS3dfa1LiT68XiOYgJLJagw>
Subject: [IPv6] Feedback on draft-evan-amateur-radio-ipv6
Precedence: list

Hi, Evan,

Some comments on the your I-D:

Abstract:
> Abstract
> 
>    This document defines a method for generating stable IPv6 Interface
>    Identifiers for amateur packet radio nodes.  This method is meant to
>    be an alternative to hardware address based Interface Identifier
>    generation such that the benefits of stable addressing may be
>    achieved even on nodes that have unstable, changing, or experimental
>    networking hardware.

This is misleading. RFC8064 recommends to use RFC7217, and recommends 
against hardware-addresses-based IIDs.



Section 1, page 2:
>    This document specifies the steps an amateur packet radio node takes
>    in order to generate a stable and unique IPv6 Interface Identifier
>    (IID) [RFC2460].  The resulting Interface Identifier SHALL be used in
>    conjunction with processes such as (but not limited to) Stateless
>    Address Autoconfiguration (SLAAC) [RFC4862], DHCPv6 [RFC3315], or
>    manual configuration to configure IPv6 connectivity on the node.

Some of these RFCs have been been revised already (e.g. RFC2460 and 
RFC3315).

Aside, there's a difference in how you'd use an algorithm with e.g. 
SLAAC vs. DHCPv6.


Section 4, page 3:
> 4.  The Algorithm
> 
>    To determine a 64 bit long [RFC4291] Interface Identifier for an
>    amateur packet radio node in conformance with this specification, the
>    following steps MUST be be taken:
> 
>    1.  Set the lest significant 4 bits of the Interface Identifier to
>        the node's ID number.
> 
>    2.  If the callsign is less than or equal to 9 characters in length:

RFC8064 recommends against patterns in IIDs.


* Section "4.5.  Benefits of this method":

Hown can an eternal entity tell whether a station is using this 
algorithm, RFC7217, manual configuration, or something else?



* Section "5.  Privacy Considerations"
> 
> 5.  Privacy Considerations
> 
>    The International Telecommunication Union requires all stations
>    operating in the amateur service to self-identify when transmitting.
>    Various countries also impose further requirements such as the
>    interval and method by which stations must identify themselves.
> 
>    The legal requirement to identify all transmissions nullifies any
>    privacy benefits gained from other privacy-aware addressing methods.

What does it mean to "self identify"? Ans why should such a "sekf 
identification" be encoded into an IPv6 address, in particular when 
systems that you're communicating with, might not even be operating in 
the radio amateur service?   (i.e., why would you want to encode the 
node identity in all your packets, for the world to see?)

Aside: if this ITU requirement motivates this work, the my question is: 
how is this requirement currently complied with for the IPv4 case?


* Section "7.  Security Considerations"

There's existing work in this area, such as RFC7721 and RFC7707.

Thanks!

Regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01

[IPv6] Feedback on draft-evan-amateur-radio-ipv6 Fernando Gont