RE: ipv6 Digest, Vol 178, Issue 79

["장종표" <[e-mail]>]

unsubscribe


--------- 원본 메일 ---------

보낸사람 : <[e-mail]>
받는사람 : <[e-mail]>
받은날짜 : 2019-02-22 (금) 08:59:04
제목 : ipv6 Digest, Vol 178, Issue 79


Send ipv6 mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/ipv6
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ipv6 digest..."


Today's Topics:

   1. Re: [v6ops] A common problem with SLAAC in "renumbering"
      scenarios (Mark Andrews)
   2. Re: [v6ops] A common problem with SLAAC in "renumbering"
      scenarios (Owen DeLong)
   3. Re: [v6ops] A common problem with SLAAC in "renumbering"
      scenarios (Lorenzo Colitti)
   4. Re: [v6ops] A common problem with SLAAC in "renumbering"
      scenarios (Lorenzo Colitti)


----------------------------------------------------------------------

Message: 1
Date: Fri, 22 Feb 2019 10:44:45 +1100
From: Mark Andrews 
To: Mark Smith Cc: Gert Doering , IPv6 Operations , "[e-mail]" <[e-mail]> Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios Message-ID: Content-Type: text/plain; charset=utf-8 > On 22 Feb 2019, at 10:21 am, Mark Smith wrote: > > On Fri, 22 Feb 2019 at 08:53, Gert Doering wrote: >> >> Hi, >> >> On Fri, Feb 22, 2019 at 08:40:24AM +1100, Mark Smith wrote: >>>> Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to >>>> learn how to deal with NAPT. New protocols that embed IP addresses are >>>> killed by IPv4 NAPT anyway, so that ship has sailed - >>> >>> Getting it back in IPv6 is one of the things I hope we can get. >>> >>> That's because applications that would be best performing, most robust and >>> more secure with a peer-to-peer communications model are forced to adopt an >>> absolute client-server model (where the server is a much more likely >>> performance bottleneck, the server becomes a SPOF for all clients using it >>> at the time, and the server is a natural interception point for a malicious >>> server operator). >> >> Have you looked out there recently? None of the big actors in the market >> seem to have any particular interest in moving away from a "we are the cloud >> content players, you are just visiting clients" model. >> > > Generally it's in their business interests not to. > > However, just like everybody else, they don't have a choice anyway, > even if they wanted to with IPv4 because of NAT. > > Still, there are lots of little actors, and a peer-to-peer model can > allow them to scale their application without having to spend massive > amounts on server infrastructure (physical or virtual.) > >> (The gaming industry has, to some extent, but that doesn't seem to be >> a really strong driver) >> > > Something significant happened in that regard recently. > > "IPv6 on Xbox One" > https://support.xbox.com/en-US/xbox-one/networking/ipv6-on-xbox-one > > "And?most useful for Xbox?the expansion removes the need for Network > Address Translation (NAT), which can interfere with multiplayer gaming > and chat over IPv4 networks." > > "..., for the best possible experience, we recommend enabling IPv6 on > your network." > >> [..] >>> Another analogy to show the significance is that with NAT in the telephone >>> network, it wouldn't be possible for me to give you this phone's number to >>> call me. Would any of us accept that constraint on the usability of our >>> phones? >> >> When did you do the last phone call on your mobile tablet-like computer >> thingie? > > Sunday (and I need to get back to my Uncle since). Previous weeks a > number of them organising a trip and updating expired credit card > number details. > > I'll observe that you've still got your phone number in your email > signature below, so being able to convey your globally unique phone > number and receive calls to it isn't yet obsolete. Actually he doesn?t. He has something that approximates a globally unique phone number. The (0) should not be there. There is a standard for writing phone numbers that start with + and it isn?t being used. > Regards, > Mark. > >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: [phone] USt-IdNr.: DE813185279 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [e-mail] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: [phone] INTERNET: [e-mail] ------------------------------ Message: 2 Date: Thu, 21 Feb 2019 15:49:27 -0800 From: Owen DeLong To: Tom Herbert Cc: Mark Smith , "Manfredi (US), Albert E" , IPv6 Operations , "[e-mail]" <[e-mail]> Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios Message-ID: Content-Type: text/plain; charset="utf-8" > Mark, > > I agreee with that with one exception. I believe that NAT/IPv4 can > offer better privacy in addressing than IPv6 given current addess > allocation methods. Huh? Random 64 bit numbers are less private than semi-opaque translation of 32 bit numbers? In today?s world (where CGN is fortunately still mostly the exception rather than the rule), the 32 bit public number (mostly) identifies the household on a transient basis. In IPv6, the 64 bit prefix (or 60 or 56 or ideally 48) similarly identifies the household, though it might be somewhat less transient than the IPv4 32 bit number. I?ve been using the same cable company for transport of my GRE tunnels that provide my real connectivity for about 10 years now. In that time, I?ve had roughly 4 address changes. Now, the rate of change there isn?t particularly relevant to my privacy (mostly it?s just a rare nuisance), but I think it probably isn?t an uncommon indicator of IPv4 address stability for people remaining on the same network. I?d say there?s not much privacy in a 32 bit space that remains persistent for more than a year. I?d argue that even if it takes 10 years to cycle an IPv6 prefix on a subscriber, you?ve still got roughly the same privacy model there at the household prefix level. On the host level, assuming that the hosts are using RFC4941, RFC7217, or RFC7943 (which most hosts use by default these days), then I think that the host portion in IPv6 is significantly more private than anything one gains from IPv4 NAT even though one does not need to sacrifice the peer-to-peer nature of the internet in order to use them (as is the case with IPv4 NAT). Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Fri, 22 Feb 2019 08:54:49 +0900 From: Lorenzo Colitti To: Fernando Gont Cc: "Manfredi (US), Albert E" , IPv6 Operations , "[e-mail]" <[e-mail]> Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios Message-ID: Content-Type: text/plain; charset="utf-8" On Thu, Feb 21, 2019 at 10:35 AM Fernando Gont wrote: > Given that RFC6092 recommends "only allow outgoing connections", RFC 6092 recommends no such thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Fri, 22 Feb 2019 08:57:57 +0900 From: Lorenzo Colitti To: Gert Doering Cc: "Manfredi (US), Albert E" , IPv6 Operations , "[e-mail]" <[e-mail]> Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios Message-ID: Content-Type: text/plain; charset="utf-8" On Thu, Feb 21, 2019 at 4:35 PM Gert Doering wrote: > Applications today seem to be all "HTTP(S)" or "QUIC", and they all had to > learn how to deal with NAPT. New protocols that embed IP addresses are > killed by IPv4 NAPT anyway, so that ship has sailed - and everything that > doesn't care about embedded IP addresses will nicely work throug NPTv6. > It has only sailed if we as an industry deploy NAT for IPv6 in a pervasive way. If we do not, and NAT66 remains an uncommon configuration, then the application breakage resulting from NAT66-only deployments will cause those deployments to roll back to IPv4 and/or global IPv6. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ ipv6 mailing list [e-mail] https://www.ietf.org/mailman/listinfo/ipv6 ------------------------------ End of ipv6 Digest, Vol 178, Issue 79 *************************************