Hi Wei,

Let me try a different approach…

Ignoring the (IMHO) technical, security/privacy, logistical, political, and 
other infeasibilities, there is a procedural matter with your proposal: RFC 
4291 states "IPv6 addresses are 128-bit identifiers for interfaces and sets of 
interfaces (where "interface" is as defined in Section 2 of [IPV6]).” Section 2 
of [IPV6] (RFC 2460) defines “interface” as "a node's attachment to a link.” It 
also defines “node” and “link” as: "a device that implements IPv6.” and "a 
communication facility or medium over which nodes can communicate at the link 
layer, i.e., the layer immediately below IPv6.” respectively.

As such, given it is impossible for a "non-electronic item” to implement IPv6 
and/or have any communication facility, it would seem you would, at the very 
least, need to revise RFC 4291.  

Clearly, the IETF, not APNIC’s policy forum, would be the appropriate place for 
that redefinition to occur. If “IPv6 addresses” were redefined by the IETF to 
include flat identifiers unrelated to being used for network interfaces, the 
RIRs could create a global policy via the processes at ICANN for the IANA 
Numbers function, after which the IANA team would delegate additional resources 
to the RIRs for subsequent allocation.

Regards,
-drc

On Aug 7, 2024, at 7:02 AM, Wesley <[email protected]> wrote:
> Thank you for sharing your expertise. I'd like to clarify the rational of the 
> proposal: we aim to innovate within the current policy framework by expanding 
> the use of IPv6 addresses, without altering the underlying IPv6 technology 
> stack. 
> Allocating IPv6 addresses to non-electronic items, is a straightforward 
> simplied expression of binding a unique IPv6 address to each data object of  
> non-electronic item. 
> 
> It is reasonable to have a specific domain name printed onto a trade mark, to 
> assist consumers in obtaining the relevant product information. This can be 
> regarded as assigning a domain name to a non-electronic item. 
> 
> Similarly, our proposal is to directly use the IPv6 address behind the domain 
> name as the primary ID to routing the user query to the exclusive data object 
> page of the corresponding item. 
> 
>  However, Using IPv6 addresses as the item identifers doesn't mean replacing 
> other identification schemes. Actually, in practice, IPv6 addresses could be 
> generated by hashing the upper layer semantic ID to the interface ID/postfix 
> 64 bits.
>  Introducing IPv6 addresses as the Item ID sets up an effective technical 
> barrier to the product counterfeiters:
>   1.   The ID owner is also the IP owner, ensuring that query traffic is 
> directed to the correct destination through BGP broadcasting.
> 
>   2.   Authenticity is ensured by existing security measures such as RPKI 
> (Resource Public Key Infrastructure) and CGA (Cryptographically Generated 
> Addresses).
> 
>   3.   Traceability is enhanced by the end-to-end transparency of the 
> network, providing clear location information for both the source and 
> destination.
> 
>   4.   Flexibility is achieved as IP address administrators can use 
> techniques like Layer 3 NAT, traffic scheduling, or Layer 7 switching to 
> direct access requests to any arbitrary IT system, ensuring seamless 
> collaboration with upper layer identification schemes .
> 
>  
> In summary, while it is theoretically possible to assign an IPv6 address to 
> every grain of sand in the world, in practice, this is unnecessary and 
> impractical for natural sand found in deserts or on beaches. However, once 
> sand is packaged or transformed into a commercial product, it may require an 
> IPv6 address for identification and to provide access to the item's 
> corresponding data object.
> 
>  
> Best,
> 
> Wei WANG
> 
> _______________________________________________
> SIG-policy - https://mailman.apnic.net/[email protected]/
> To unsubscribe send an email to [email protected]
> 


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]

Reply via email to