Re: AT&T UVERSE Native IPv6, a HOWTO
> De : Rob Seastrom > > This space wouldn't be used much anyway, > > given that most 6RD routers use only one /64, sometimes two. > > I argue that a /60 is actually the best compromise here, from > > a space and usage point of view. > > IPv4-thinking. In the fullness of time this line of reasoning [...] Hopefully, the fullness of time won't apply to 6RD (this is what was being discussed here, not dual-stack). Most MSOs are planning /56s for native. ARIN 2011-3 is great, but it came a bit late (January 2012) for those who already had planned their network. /JF
Re: AT&T UVERSE Native IPv6, a HOWTO
> De : Mikael Abrahamsson > A : Mark Andrews , > >>> You can hand out /48 as easily with 6rd as you can natively. > > "As easily". It's easier to either hand out /64 by means of 1:1 mapping > IPv4 and IPv6, or (if ability exists) hand out /48 or /56 using PD, than > to get into the whole backend mess of having multiple 6RD domains with > multiple configs per IPv4 subnet etc. > > I agree with you theoretically, but in practice I disagree. Some hard data points here, coming from one of the rare operator who actually deployed 6RD sub-domains to all its customers (to my knowledge). In practice, most 6RD implementations that support option 212 do support IPv4MaskLen properly these days. It wasn't the case 3 years ago, but we worked a lot with vendors to make it right. Seems ok now, we mostly have a 6RD population of D-Link and Cisco/Linksys. On the backend side, it's really not that bad. A one-page TCL handles around 15-16 sub-domains for us without noticeable impact on the DHCP servers CPU. Configuring the relays with all the tunnels can be a bit of fun playing with hex maths, but it's not too bad either. So I agree with Mark, it's not that complex. I can't agree with him on the prefix size though. We hand out /60s because we feel it's enough from a transition point of view (these are short-lived anyway) and offering a bigger size would really use too much space. Offering /48s out of a single /16 block, to take a simple example, would use a whole /32. This space wouldn't be used much anyway, given that most 6RD routers use only one /64, sometimes two. I argue that a /60 is actually the best compromise here, from a space and usage point of view. /JF Videotron, AS5769
Re: The block message is 521 DNSRBL: Blocked for abuse
> > Our mail server IP address is 74.112.99.25. Is it possible they > are blocking us based on old information from the previous IP > address block owner? > > Quite likely, yes. https://www.arin.net/resources/whowas/ Found it to be of use for this type of question. Registration required. Geolocation information often needs updating for these "recycled" ranges. /JF
RE: Plages d'adresses IP Orange
Jamie Bowden a écrit sur 19/11/2012 12:16:31 PM : > Having said that, I can't recall having seen any Quebecois posting > in French here, [snip] The intersection of Quebecois who speak only French and those who have anything to do with networking is hopefully very close to 0. That said, our typical first-encounter joke with a vendor is asking for a French version of their CLI. Always funny to see how they react. /JF Videotron, AS5769
Re: using "reserved" IPv6 space
TJ a écrit sur 13/07/2012 02:47:26 PM : > Of the top of my head, the first problem you might hit there is > WRT multicast ... > (ULA might "win" some source address selections that you want GUA to win) > /TJ Good point, thanks for pointing that out. We'll see when we deploy network-wide IPv6 multicast... not there (yet). /JF
Re: using "reserved" IPv6 space
-Hammer- a écrit sur 13/07/2012 12:21:13 PM : > I like the ULA approach. Global and ULA are two approach, but there's a third one: GUA + ULA. We actually put a GUA on servers speaking publicly, a ULA on servers speaking in our domain only and *both* ULA and GUA on servers which talk both ways. Our datacenter firewalls are configured to enforce GUA-GUA and ULA-ULA connections only (just simple URPF over two interfaces). This setup works very well, surprisingly we've had very little source address selection problems so far (knock on wood). We're very happy that the separation between public and "private" networks is clear, it helps a lot with debugging and service separation. /JF
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
Karl Auer a écrit sur 07/06/2012 06:09:46 PM : > On this point I think you are wrong. Except for router advertisements, > most NDP packets are sent to a solicited node multicast address, and so > do NOT go to all nodes. It is "the same as broadcast" only in a network > with switches that do not do MLD snooping. > > > So I'm not sure how DAD traffic would exceed ARP traffic. > > I wouldn't expect it to. > Nor would I - which was the point of my response to an original poster > who said it might. Karl, Actually, your analysis seems fair for a normal broadcast network. It's true that DAD is fairly rare. RS and RAs are also part of ND though, but they shouldn't be a large part of the trafic. My comment was probably skewed by my perspective as an MSO. Docsis networks are not really broadcast in nature and the gateway (CMTS) sees all the ND trafic (ND-proxying), including DAD and RS, which can become a fair amount of trafic in some specific situations. /JF
IPv6 /64 links (was Re: ipv6 book recommendations?)
Anton Smith a écrit sur 06/06/2012 09:53:02 AM : > Potentially silly question but, as Bill points out a LAN always > occupies a /64. > > Does this imply that we would have large L2 segments with a large > number of hosts on them? What about the age old discussion about > keeping broadcast segments small? The /64 only removes the limitation on the number of *addresses* on the L2 domain. Limitations still apply for the amount of ARP and ND noise. A maximum number of hosts is reached when that noise floor represents a significant portion of the link bandwidth. If ARP/ND proxying is used, the limiting factor may instead be the CPU on the gateway. The ND noise generated is arguably higher than ARP because of DAD, but I don't remember seeing actual numbers on this (anybody?). I've seen links with up to 15k devices where ARP represented a significant part of the link usage, but most weren't (yet) IPv6. /JF
CGN and CDN (was Re: what about the users re: NAT444 or ?)
> And these 'perceived' routing issues won't be noticed nor are they > important to CDN's? > I know what my job is, but that may not matter to the CDN's. Reading > this thread, I wanted to mention another problem that I feel has an > effect on this issue. > Lyle A very interesting point. In order to save precious CGN resources, it would not be surprising to see some ISPs asking CDNs to provide a private/non-routed behind-CGN leg for local CDN nodes. For this to work, the CGN users would probably have a different set of DNS servers (arguably also with a private/non-routed leg) or some other way to differentiate these CGN clients. Lots of fun in the future debugging that. /JF
Re: NAT444 or ?
>> However these are with a very high address-sharing ratio (several >> thousands users per address). Using a sparser density (<= 64 users per >> address) is likely to show much less dramatic user impacts. > > I think you have the numbers off, he started with 1000 users sharing > the same IP, since you can only do 62k sessions or so These numbers were not off. From page 19: "...we should assign at least 1000 [..] ports per customer to assure good performance of IPv4 applications" "At least 1000 ports per customers" is roughly the same than "less than 64 users per address" as I stated above. Btw, 90% of subscribers have less than 100 active connections at any time, if I read these tiny graphs correctly: http://www.wand.net.nz/~salcock/pam2009_final.pdf > and with a "normal" timeout on those sessions you ran into issues quickly. Agreed for UDP, but most of these sessions are TCP, which arguably time out rather rapidly after a FIN and an extra hold time. Normal duration of a TCP session is usually under a few seconds. This study saw an average connection time of 8 seconds for DSL, but it's from 2004. http://www.google.com/#q=A+Comparative+Study+of+TCP/IP+Traffic+Behavior+in+Broadband+Access+Networks /JF
Re: NAT444 or ?
On Wed, Sep 07, 2011 at 12:16:28PM +0200, Randy Bush wrote: > > I'm going to have to deploy NAT444 with dual-stack real soon now. > you may want to review the presentations from last week's apnic meeting > in busan. real mesurements. sufficiently scary that people who were > heavily pushing nat444 for the last two years suddenly started to say > "it was not me who pushed nat444, it was him!" as if none of us had a > memory. > > Hm, I fail to find relevant slides discussing that. Could you please > point us to those? I had the same question. I found Miyakawa-san's presentation has some dramatic examples of CGN NAT444 effects using Google Maps: http://meetings.apnic.net/__data/assets/file/0011/38297/Miyakawa-APNIC-KEYNOTE-IPv6-2011-8.pptx.pdf However these are with a very high address-sharing ratio (several thousands users per address). Using a sparser density (<= 64 users per address) is likely to show much less dramatic user impacts. /JF
