Well don’t put an IPv4 stack on the device. Use mapped addresses over IPV6
sockets and map those addresses to the PREF64 prefix in use in the stack.
--
Mark Andrews
> On 8 Jul 2023, at 05:20, Ted Lemon wrote:
>
>
> John, that's simply not an option on networks that only support IPv6 (most
John, that's simply not an option on networks that only support IPv6 (most
especially 6lowpan). We really don't want to have to put an IPv4 stack in a
constrained device. So this solution isn't going to work. In practice,
these devices will generally just rely on a resolver that probably /does/
hav
It appears that Vasilenko Eduard said:
>-=-=-=-=-=-
>1. 464XLAT is indeed an alternative, but a bad one: it means that the client
>should have a local IPv4 subnet.
>The DNS resolver should prepare the packet in IPv4 format, then fetch it to
>the CLAT engine where it would be translated to IPv6.
Hi Ted,
(Changed the subject for convenience)
I was told that PCP was required in Matter/Thread(?). Do you know if the
discovery of the prefix is based on RFC7225? Thanks.
For your last point: problems may arise if a distinct pref64 is used by the
upstream DNS64 than the one used locally. Unle
FWIW the approach we took for Thread was to require that devices do DNS64
locally, which is consistent with what you are saying, Med. So Thread BRs
do not do DNS64: they provide a NAT64 prefix that hosts on the Thread mesh
can use to synthesize IPv6 addresses after the resolver has discovered them.
Hi all,
> So instead of creating documents for every possible protocol that
> uses IPv4 literals, why not create one document that describes how
> to deal with IPv4 literals in existing protocols in the context of
> NAT64?
>
We do already have rfc7051 + many pref64 discovery RFCs out there. RFC7
Reviewer: Vladimír Čunát
Review result: Ready
(assigned review) I re-read the whole text, and noticed nothing that I'd
consider wrong or missing. (I didn't review implementation section; except
Knot's is basically my text.)
I think the current text is a quite nice reference for DNS fragmentatio
> I agree with you that 464XLAT is a better solution and the world
> should use it as much as possible.
>
> But for those already deployed DNS64 and can't move to 464XLAT soon
> (possibly due to lack of CLAT support, e.g. in some residential
> gateways), wouldn't Momoka's draft help? If Momoka ad
Hi Mark,
I agree with you that 464XLAT is a better solution and the world should use it
as much as possible.
But for those already deployed DNS64 and can't move to 464XLAT soon (possibly
due to lack of CLAT support, e.g. in some residential gateways), wouldn't
Momoka's draft help? If Momoka a
On 2023-07-07, at 09:26, Esko Dijk wrote:
>
> In the last interim meeting presentation “security” was a key driver for this
> draft. Which is a very good one; compared to non-secured DNS as the
> alternative.
>
> Firmware size and code complexity/BOM are also relevant if this protocol can
>
Hi Mukund,
Many thanks for the detailed review.
We updated the spec to address many of your suggestions. We added in particular
text to explain the rationale for having c/j mandatory for IT teams and also
added text to explain why suberr is defined rather than consuming ede codes.
However, n
Hi Mark,
1. 464XLAT is indeed an alternative, but a bad one: it means that the client
should have a local IPv4 subnet.
The DNS resolver should prepare the packet in IPv4 format, then fetch it to the
CLAT engine where it would be translated to IPv6.
It is not an IPv6-only network. You have to
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain Name System
Operations (DNSOP) WG of the IETF.
Title : Structured Error Data for Filtered DNS
Authors : Dan Wing
Tirumales
In the last interim meeting presentation "security" was a key driver for this
draft. Which is a very good one; compared to non-secured DNS as the
alternative.
Firmware size and code complexity/BOM are also relevant if this protocol can
avoid pulling in extra components (TLS/DTLS) that would ot
14 matches
Mail list logo
