Re: [v6ops] draft-vf-v6ops-ipv6-deployment

[Alexandre Petrescu <[e-mail]>]

Le 24/03/2021 à 15:48, JORDI PALET MARTINEZ a écrit :
> I think you need to read the NAT64 and related RFCs ...
> 
> If your ISP doesn't offer the NAT64, then it is really bad to use 
> IPv6-only in your network.

?

No no, I live well in the IPv6 world without NAT64... I dont understand
why NAT64 is so required?

> I may understand that you do that as an experiment, but then you can
> setup your own NAT64, it is really simple in any Linux or even an
> OpenWRT CPE.

I dont want to set up new boxes at home.  It is indeed possible, but at 
this time I do not want.

> You may also setup a DNS64 and I will suggest also to setup a CLAT, 
> all that can be done via VMs, even a single VM in your own network.

YEs, that is possible too.

But can I do without it please?

Does IPv6 mandate the use of DNS64 and NAT64?

Alex

> 
> Regards, Jordi @jordipalet
> 
> 
> 
> El 24/3/21 15:33, "v6ops en nombre de Alexandre Petrescu" 
> <[e-mail] en nombre de [e-mail]> 
> escribió:
> 
> Hi, Gabor,
> 
> Thanks for the reply.  Allow me to continue this discussion.
> 
> Le 24/03/2021 à 13:11, Gabor LENCSE a écrit :
>> Dear Alex,
>> 
>> I meant that you need to do the address synthesis manually. I 
>> intended the 64:ff9b::/96 WKP only as an example.
> 
> As a side note,  I think that 64:ff9b::/96 prefix might need a 32bit
>  IID, which is probably forbidden by the IPv6 Addressing
> Architecture RFC 4291 ("For all unicast addresses, except those that
> start with the binary value 000, Interface IDs are required to be 64
> bits long").
> 
> This is not to say that I disagree with the 64:: prefix, but maybe 
> point to what appears to me to be a slight incoherency.
> 
>> First, you need to find out the NAT64 prefix used by your ISP. (RFC
>> 7050 describes the process.)
> 
> I wanted to ask: do you mean the NAT64 prefix that my ISP uses, or 
> the ISP that the data provider (the URL in question) uses?
> 
> I am saying this because I think my ISP does not provide NAT64 
> service to home.  It is probably an optional feature.
> 
>> Then, you can synthesize and use the proper IPv4-Embedded IPv6 
>> Address. (I hope that the IPv6 routing will find the NAT64 gateway
>>  based on the NAT64 prefix.)
>> 
>> Of course, it is just a hack, DNS64 makes our life easier, if the 
>> IPv4 only server is registered in the DNS system. And, naturally, 
>> the real solution is that the server should have an IPv6 address. 
>> :-)
> 
> Yes, I agree with it too.
> 
> Alex
> 
>> 
>> Best regards,
>> 
>> Gábor
>> 
>> On 3/24/2021 10:59 AM, Alexandre Petrescu wrote:
>>> 
>>> :-)
>>> 
>>> 
>>> Le 24/03/2021 à 09:39, Gabor LENCSE a écrit :
>>>> Of course, it is better to use DNS,
>>> 
>>> 
>>> I agree.
>>> 
>>> 
>>>> but if you have only an IPv4 literal AND you know the NAT64 
>>>> prefix used in your network, then you can synthesize the (RFC 
>>>> 6052) IPv4-embedded IPv6 address manually. :-)
>>> 
>>> 
>>> For that to work there is a need to implement some conversion in 
>>> a network box (NAT64?  464XLAT?) _and_ in the client.
>>> 
>>> 
>>>> 
>>>> The URL would look like:
>>>> 
>>>> https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate
>>> 
>>> 
>>> thanks for the converted URL.
>>> 
>>> I clicked on it in my Mail User Agent (MUA) client Thunderbird on
>>> an IPv6-only PC and it quickly complains about something that 
>>> might relate to security.  It complains about it very quickly, 
>>> there is no circling pointing to wait for response of 
>>> discoverying some server in the infra, or waiting reply from a 
>>> site.
>>> 
>>> It says: "The link text indicates 'A' but it leads to 'A'" where 
>>> A is the hex text with ":" everywhere converted from the hex you
>>>  provided above containing 4 dots.  Remark A is the same as A, 
>>> and the error reporting is wrong.  That is a client problem that
>>>  deserves correction (a bug).
>>> 
>>> But it is a larger client problem too in that clients on PCs dont
>>> have that support for '64::' addresses.  Smartphones might have
>>> that support.  I am not sure it is good to consider that lack of
>>> implementation of "64::" addresses in clients to be a bug.
>>> 
>>> 
>>> Alex
>>> 
>>> PS: for firefox: when I copy paste that URL 
>>> https://[64:ff9b::218.2.231.237]:5001/cgi-bin/generate on my 
>>> address bar of web browser firefox on my IPv6-only PC it tries to
>>> connect to something, waitslike 10 seconds, and then firefox 
>>> reports 'The wait delay has been reached' (translated) and stops
>>>  waiting.  Firefox is also affected by this problem in
>>> protocols.
>>> 
>>> 
>>>> 
>>>> Hopefully, your ISP uses a Network-Specific Prefix, and not the
>>>> NAT64 Well-Known Prefix.
>>>> 
>>>> Gábor
>>>> 
>>>> On 3/24/2021 9:02 AM, JORDI PALET MARTINEZ wrote:
>>>>> It will be much better to use DNS, not literals!
>>>>> 
>>>>> You probably don't see that from an IPv6-only network because
>>>>> it is a literal (if you have NAT64+DNS64 it will work with
>>>>> DNS, if you have 464XLAT it will also work with a literal
>>>>> IPv4).
>>>>> 
>>>>> El 24/3/21 8:53, "v6ops en nombre de Alexandre Petrescu" 
>>>>> <[e-mail] en nombre de 
>>>>> [e-mail]> escribió:
>>>>> 
>>>>> 
>>>>> 
>>>>> Le 24/03/2021 à 04:14, hsyu a écrit :
>>>>>> Dear Paolo and  Alexandre，
>>>>>> 
>>>>>> Thank you very much for your interest in this website. This
>>>>>> is a test website, and the current data still
>>>>> needs
>>>>>> further confirmation. Therefore, I will post it after the
>>>>> data is corrected.
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Thank you for the reply.
>>>>> 
>>>>> The data on the website might be correct already.  I can see
>>>>>  it on an IPv4 connection.
>>>>> 
>>>>> But the access to that data should be on IPv6 too, not only 
>>>>> on IPv4.
>>>>> 
>>>>> Ideally, one should add an IPv6 address to the computer's 
>>>>> interface. Then the URL would be something like 
>>>>> https://[2001:db8:1::1]:5001/cgi-bin/generate (attention that
>>>>> is an IPv6 address for documentation, do not put that 
>>>>> particular address on the interface)
>>>>> 
>>>>> Alex
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Haisheng Yu(Johnson) [e-mail]
>>>>>> 
>>>>>> 
>>>>> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=Haisheng+Yu%28Johnson%29&uid=hsyu%40cfiec.net&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fsm50a1433bca9fb284d4265d35e9ed54d3.jpg&items=%5B%22%22%2C%22hsyu%40cfiec.net%22%2C%22%22%2C%22%22%2C%22%22%5D>
>
>>>>>
>>>>> 
>>>> 
>>>>> 
>>>>> 
>> 
>>>>>> 签名由 网易邮箱大师
>>>>> <https://mail.163.com/dashi/dlpro.html?from=mail81>
>>>>>> 定制 On 3/24/2021 02:14，Alexandre
>>>>> Petrescu<[e-mail]>
>>>>>> <mailto:[e-mail]> wrote：
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Thank you for the link in China about IPv6 deployment.
>>>>>> 
>>>>>> But I can not see it :-(
>>>>>> 
>>>>>> When I copy paste that link
>>>>> (http://218.2.231.237:5001/cgi-bin/generate)
>>>>>> in my web browser  it responds that the connection has
>>>>> failed.  I use an
>>>>>> IPv6-only computer (Windows with IPv4 unchecked in the
>>>>> interface
>>>>>> Properties).
>>>>>> 
>>>>>> Ideally, one would put data about IPv6 on a server that
>>>>> is also capable
>>>>>> of doing IPv6.
>>>>>> 
>>>>>> Maybe one can put an IPv6 address on the server
>>>>> 218.2.231.237?
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>> 
>>>>>> Le 23/03/2021 à 07:21, hsyu a écrit :
>>>>>> 
>>>>>> Hi Paolo, I can also provide some data on the
>>>>> deployment of IPv6 in
>>>>>> China. http://218.2.231.237:5001/cgi-bin/generate
>>>>>> 
>>>>>> Best regards.
>>>>>> 
>>>>>> Haisheng Yu(Johnson) [e-mail]
>>>>>> 
>>>>>> 
>>>>> <https://maas.mail.163.com/dashi-web-extend/html/proSignature.html?ftlId=1&name=Haisheng+Yu%28Johnson%29&uid=hsyu%40cfiec.net&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fsm50a1433bca9fb284d4265d35e9ed54d3.jpg&items=%5B%22%22%2C%22hsyu%40cfiec.net%22%2C%22%22%2C%22%22%2C%22%22%5D>
>
>>>>>
>>>>> 
>>>> 
>>>>> 
>>>>> 
>> 
>>>>>> 
>>>>>> 签名由 网易邮箱大师 <https://mail.163.com/dashi 
>>>>>> /dlpro.html?from=mail81> 定制 On 3/23/2021 12:40，Dhruv 
>>>>>> Dhody<[e-mail]> <mailto:[e-mail]> 
>>>>>> wrote：
>>>>>> 
>>>>>> Hi Paolo,
>>>>>> 
>>>>>> I think we should highlight that we do not have
>>>>> visibility
>>>>>> inside the enterprises beyond the external-facing website 
>>>>>> or
>>>>>> 
>>>>> email and thus it
>>>>>> is also difficult to gauge the IPv6 deployments
>>>>> inside enterprises.
>>>>>> 
>>>>>> [PV] Ok. Probably here you refer to small-medium
>>>>> enterprises. For
>>>>>> large enterprises public data on the usage of IPv6
>>>>> can be retrieved
>>>>>> (Nalini, in copy, provided a good input on IPv6 in large 
>>>>>> organizations). We will better specify this point in
>>>>> the next
>>>>>> version of the draft.
>>>>>> 
>>>>>> 
>>>>>> I had this NIST data in mind - 
>>>>>> https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com
>
>>>>>>
>>>>>> 
>>>> which
>>>>>> includes large enterprises and relies on DNS, mail,
>>>>> external
>>>>>> website. Also, see Eric's site - 
>>>>>> https://www.vyncke.org/ipv6status/detailed.php?country=in
>>>>>> 
>>>>>> Thanks! Dhruv
>>>>>> 
>>>>>> _______________________________________________ v6ops 
>>>>>> mailing
>>>>>> 
>>>>> list
>>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ v6ops 
>>>>>> mailing
>>>>>> 
>>>>> list
>>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>>>>>> 
>>>>> 
>>>>> _______________________________________________ v6ops mailing
>>>>> list [e-mail] 
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>> 
>>>>> 
>>>>> 
>>>>> ********************************************** IPv4 is over 
>>>>> Are you ready for the new Internet ? 
>>>>> http://www.theipv6company.com The IPv6 Company
>>>>> 
>>>>> This electronic message contains information which may be 
>>>>> privileged or confidential. The information is intended to be
>>>>> for the exclusive use of the individual(s) named above and
>>>>> further non-explicilty authorized disclosure, copying, 
>>>>> distribution or use of the contents of this information, even
>>>>> if partially, including attached files, is strictly 
>>>>> prohibited and will be considered a criminal offense. If you 
>>>>> are not the intended recipient be aware that any disclosure, 
>>>>> copying, distribution or use of the contents of this 
>>>>> information, even if partially, including attached files, is 
>>>>> strictly prohibited, will be considered a criminal offense, 
>>>>> so you must reply to the original sender to inform about
>>>>> this communication and delete it.
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ v6ops mailing
>>>>> list [e-mail] 
>>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>> 
>>>> 
>>>> _______________________________________________ v6ops mailing 
>>>> list [e-mail] 
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>> 
>>> _______________________________________________ v6ops mailing 
>>> list [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> ********************************************** IPv4 is over Are you 
> ready for the new Internet ? http://www.theipv6company.com The IPv6 
> Company
> 
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents 
> of this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If
> you are not the intended recipient be aware that any disclosure,
> copying, distribution or use of the contents of this information,
> even if partially, including attached files, is strictly prohibited,
> will be considered a criminal offense, so you must reply to the
> original sender to inform about this communication and delete it.
> 
> 
> 
> _______________________________________________ v6ops mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>