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. RFC7051 says:
Below is (an incomplete) list of various
use cases where it is beneficial for a host or an application to know
the presence of a NAT64 and the NSP/WKP:
o ..
o Protocols that use IPv4 literals. In IPv6-only access, native
IPv4 connections cannot be created. If a network has NAT64, it is
possible to synthesize an IPv6 address by combining the IPv4
literal and the IPv6 prefix used by NAT64. The synthesized IPv6
address can then be used to create an IPv6 connection.
o ...
o URI schemes with host IPv4 address literals rather than domain
names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1,
ipp://192.0.2.1). A host can synthesize an IPv6 address out of
the literal in the URI and use IPv6 to create a connection through
NAT64.
Cheers,
Med
> -----Message d'origine-----
> De : DNSOP <dnsop-boun...@ietf.org> De la part de Philip Homburg
> Envoyé : vendredi 7 juillet 2023 12:18
> À : v6...@ietf.org
> Cc : Xipengxiao <xipengxiao=40huawei....@dmarc.ietf.org>; dnsop
> <dnsop@ietf.org>
> Objet : Re: [DNSOP] [v6ops] WG call for adoption: draft-momoka-
> v6ops-ipv6-only-resolver-01
>
> > 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 adds
> statements in
> > a new version telling people to consider 464XLAT first, will it
> be
> > acceptable to you? Thanks.
>
> NAT64 without 464xlat is a rather broken way of providing access
> to the IPv4 internet because it cannot deal with IPv4 literals.
>
> 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?
>
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
