Dear IPv6 WG list members,
IANA hast allocated some new special purpose IPv6 prefixes in the last months
[1]. Two have already been allocated before the last RIPE meeting and one has
been allocated yesterday. This may need filtering at the network edges.
3fff::/20 -> Documentation
Abstract from the the IETF document [2]:
"The document describes the reservation of an additional IPv6 address prefix
for use in documentation. This update to RFC 3849 expands on the existing
2001:db8::/32 address block with the reservation of an additional, larger
prefix. The addition of a /20 allows documented examples to more closely
reflect a broader range of realistic, current deployment scenarios and more
closely aligns with contemporary allocation models for large networks."
5f00::/16 -> Segment Routing (SRv6) SIDs
Abstract from the the IETF document [3]:
"The data plane for Segment Routing over IPv6 (SRv6) is built using IPv6 as
the underlying forwarding plane. Due to this underlying use of IPv6, Segment
Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and behave like
them while exhibiting slightly different behaviors in some situations. This
document explores the characteristics of SRv6 SIDs and focuses on the
relationship of SRv6 SIDs to the IPv6 Addressing Architecture. This document
allocates and makes a dedicated prefix available for SRv6 SIDs."
2001:1::3/128 -> DNS-SD Service Registration Protocol Anycast Address
Abstract from the the IETF document [4]:
"The Service Registration Protocol for DNS-Based Service Discovery uses the
standard DNS Update mechanism to enable DNS-Based Service Discovery using only
unicast packets. This makes it possible to deploy DNS Service Discovery
without multicast, which greatly improves scalability and improves performance
on networks where multicast service is not an optimal choice, particularly
IEEE 802.11 (Wi-Fi) and IEEE 802.15.4 networks. DNS-SD Service registration
uses public keys and SIG(0) to allow services to defend their registrations."
[1]
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-speci…
[2] https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/05/
[3] https://datatracker.ietf.org/doc/draft-ietf-6man-sids/06/
[4] https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/25/
Kind regards
Chris
Good morning all,
I have a question about chromecast audios
[https://www.whathifi.com/google/chromecast-audio/review] and their
operation on an IPv6-only mostly LAN.
Several months ago, following the great tutorial Ondřej Caletka from the
RIPE NCC did and then the talk Jen Linkova did in Tuesday's plenary at
RIPE87 in Rome, I deployed a new Vlan in my home network to test the use
of option 108 etc. It worked a treat to the point where I believed I'd
tested any potential corner cases and so a few weeks back I transitioned
to deploying it on my main home network vlan. Once again I thought
everything worked a treat and got no complaints until recent days when
my wife tried to stream some music to an old chromecast audio device we
use to connect to some wired ceiling speakers.
Having looked into the issue it would appear that the chromecast audio
can't/won't do v6 and this is something that caught me on the hop a
little. Those devices that are dual-stacked continue to see and can make
use of this chromecast audio but those devices that are happily working
away and utilising the option 108 to not have v4 (such as my wife's
mobile device) can no longer see/communicate with the chromecast.
I guess my question out of all of this is if any of you have run up
against this particular problem and if so what was your solution. I
suppose in theory it doesn't need to be a chromecast, I guess any device
that's unable or unwilling to use v6. How have you managed direct
communications between two devices on the same LAN segment whereby one
device is doing v6 only and the other refuses to use v6 and will only
use v4?
I'd dearly love to avoid having to turn off option 108 on the main network.
Thanks,
--
Mick O’Donovan
Senior Network Engineer
HEAnet CLG
Ireland's National Education and Research Network
3rd Floor, North Dock 2 | 93/94 North Wall Quay | Dublin D01 V8Y6 | Ireland
+353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie
Registered in Ireland, No. 275301 | CRA No. 20036270
