Re: mpls switches

[George, Wes]

On 4/12/16, 9:22 AM, "NANOG on behalf of Tim Jackson"
 wrote:


>>> (Broadcom chipset,
>> approach with caution).
>
>QFX5100 works fine for MPLS.. [snip] QFX5100 is a
>great P and lightweight PE..

WG] For some values of "fine" and "great" perhaps, but emphasis on the
"lightweight" is important, as its suitability is heavily dependent on
your intended use case.
Use it with a few thousand routes and nothing particularly exotic as far
as features go and you should be fine. However, there are sometimes little
gotchas where established features (esp in MPLS) either are missing or
behave differently in subtle ways compared with more traditional JunOS
routers like the MX. Some of these are limitations in the Broadcom chipset
and some are driven by customer demand prioritizing feature completion.

Test carefully, and regard the higher-end multidimensional/route scale
numbers with healthy skepticism.


Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---





This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Another Big day for IPv6 - 10% native penetration

[George, Wes]

On 1/4/16, 11:54 AM, "NANOG on behalf of Neil Harris"
 wrote:


>I can only imagine the scale of the schadenfreude IPv6 proponents will
>be able to feel once they're able to start talking about IPv4 as a
>legacy protocol.

*start*?
https://www.flickr.com/photos/n3pb/sets/72157634324914351/

:-)


Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---






This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: How to force rapid ipv6 adoption

[George, Wes]

On 10/2/15, 10:48 AM, "NANOG on behalf of Cryptographrix"
 wrote:

>For ISPs that already exist, what benefit do they get from
>providing/allowing IPv6 transit to their customers?

If they'd like to continue growing at something above churn rate, they
need additional IP addresses to give their new customers.
Buying those addresses, undertaking projects to free up addresses from
other internal uses, or using CGN to share existing ones all have
nontrivial costs. The fewer things they need to make work on legacy IPv4,
the lower those costs can be (less CGN capacity since IPv6 traffic
bypasses the NAT, less support costs because less stuff breaks by going
through the NAT, etc).[1,2,3] But that's dependent on content and CPE
supporting it, so a number of large ISPs have chosen to go ahead and
deploy[4], and focus on pushing the progress on the other fronts so that
they can see that benefit of deploying.

Wes George


[1] https://www.nanog.org/meetings/abstract?id=2025

[2] https://www.nanog.org/meetings/abstract?id=2075

[3] http://nanog.org/meetings/abstract?id=2130

[4] http://www.worldipv6launch.org/measurements/


Anything below this line has been added by my company’s mail server, I
have no control over it.
---










This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: How to force rapid ipv6 adoption

[George, Wes]

From: Cryptographrix <cryptograph...@gmail.com<mailto:cryptograph...@gmail.com>>
Date: Friday, October 2, 2015 at 12:35 PM
To: "George, Wes" <wesley.geo...@twcable.com<mailto:wesley.geo...@twcable.com>>
Cc: "nanog@nanog.org<mailto:nanog@nanog.org>" 
<nanog@nanog.org<mailto:nanog@nanog.org>>
Subject: Re: How to force rapid ipv6 adoption

Unfortunately, the files at the NANOG links you posted are not available, but I 
think I get the premise of them from their summaries and what you're trying to 
say - thank you for linking.

WG] hmm, hopefully someone reading from NANOG will unbork the URLs. If nothing 
else, they post the presentation videos to their youtube channel, so you can 
find it there by going directly.

It makes me curious about the churn rate between ISPs, but that's a different 
topic and everything you've said is spot on.\
WG] in this context I was talking about churn within the ISP rather than 
between them, and it probably would have been more accurate to talk in terms of 
net customer growth – how many customers do you lose vs how many new ones you 
add?

What seems really important/would be progressive at the moment is that vendors 
release IPv6-capable "plug and play" gear.
WG] and that's a mixed bag. Many routers, all computers, smartphones, tablets, 
etc are plug and play for IPv6, but the IoT widgetry, video streaming devices, 
etc have a ways to go yet. Lots of folks like me pulling every lever we can 
find to make sure our vendors and partners in CPE and content land understand 
that IPv6 is a requirement, but it's little by little and progress is slow.

Is there any vendor that's currently working on a home router that provides 
*only* IPv6 internally, with NAT64 IPv6->IPv4?
WG] well, TMobile has a considerable amount of IPv6-only Android devices on 
their mobile network using 464xlat as the shim. On the home router side, there 
are devices that are capable of terminating an IPv6 in IPv4 tunnel to allow 
people to hop over their ISP that isn't supporting IPv6 and dual stack their 
home. Lots of us use this method + a tunnel provider like HE to have IPv6 at 
home, but that's becoming less important as Comcast and TWC and other broadband 
providers enable IPv6 for real across their networks. There are also devices 
that can do DSLite so that it's IPv6-only out of the house (encapsulate IPv4 in 
IPv6 to a remote NAT), but still supports dual-stack in the house. The number 
of devices in the average house that don't support IPv6 makes IPv6-only in the 
house problematic and a much longer-term goal.

If we wanted to really get this started, that (and a bunch of articles about 
"use this router to get IPv6 in your house") sounds like it could be really 
productive.
WG] Generally my philosophy has been that customers just want their internet 
service to work, not know anything about which IP stack they're using, and thus 
IPv6 isn't a value-added feature that you can sell to the average folks buying 
a cheap plastic router off of Amazon. Now that we're seeing evidence that IPv6 
is faster, there's a potential marketing angle for gamers (better network 
performance!!!) but we're still building the case for that, and tunnels tend to 
negate those sorts of benefits (you need native IPv6) so that's probably 
premature.

Additionally, is it possible for ISPs to offer IPv6 transit-exclusive plans for 
people that would like to get just that?
WG] I think that day is coming, but not yet. There has to be a critical mass of 
common/important IPv6-enabled content and devices, and the problem is that most 
of the folks who know enough about networking to know that they only need IPv6 
probably still need IPv4 (see also previous comment). But if someone only uses 
their internet connection for webmail (G or Y!) and Facebook and maybe a little 
Youtube with a small subset of devices, it's workable today, and it keeps 
getting more workable, either with or without an IPv4 shim like 464Xlat or 
NAT64/DNS64. It's really a question of when you get far enough along to be 
confident that it's reliable enough for average customers (for some value of 
"average") without making the phone ring.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no 
control over it.
---




This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail i

Re: NetFlow - path from Routers to Collector

[George, Wes]

On 9/1/15, 1:36 PM, "NANOG on behalf of Roland Dobbins"
 wrote:

>It should've already been spent for an OOB/DCN network, which should've
>been provisioned with flow telemetry in mind.

I'm going to interpret that "should" in the same way as the MUST in
RFC6919. :-)
Yes, it's a good practice, but like most other proactive security
measures, is extremely hard to justify spending money on it to avoid the
risk that it breaks fantastically when it is needed most.
Though you could provide a little insurance against the problem you're
highlighting here via a QoS policy that prioritizes flow data over
customer traffic.


Several of the OOB networks/designs I'm familiar with significantly
predate the entire concept of flow telemetry, as well as my own networking
career, and are still rocking the same set of Cisco 2500 routers with
async cards (many with uptimes measured in years) and 64k leased lines or
dialup on demand they've been using for literally almost 2 decades. When
one of those ancient devices dies of old age, you scrounge for the
cheapest equivalent you can find to replace it to maintain your oob access
to the 9600/8/1/none console ports for when things have gone truly
pear-shaped.
Often there is a separate management network that can deal with ethernet
speeds, but it's separate for security reasons and not always as rigidly
independent from the in band network for connectivity, i.e. It might be a
VPN riding over the regular network and thus not completely protected from
the problem you're concerned about.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
---








>


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ISP DHCPv6 and /48

[George, Wes]

On 7/10/15, 6:34 AM, NANOG on behalf of Baldur Norddahl
nanog-boun...@nanog.org on behalf of baldur.nordd...@gmail.com wrote:


Perhaps the problem is that DHCPv6-PD is not intelligent enough. Yes there
is a provision such that the user CPE could give a hint of how much space
is want, but no, it doesn't work.
WG] Sorry, [citation needed]. We are using DHCPv6-PD that listens for and
responds properly to hints in production for millions of customers. Many
of the cheap plastic routers are even smart enough to stand up their own
DHCPv6 server so that they can do PD to give out /64s to subtended devices
or split out the /56 or /60 that they were given to their WAN, LAN, and
Guestnet so that each has its own subnet. Now you may have to specify a
list of devices that properly support PD such that you know they will work
with this configuration of multiple routers behind a switch, but requiring
your customers to use a device that supports your implementation of a
feature that they want isn't really that much of an imposition on them.
You wouldn't blame the protocol when IPv6 doesn't work for your customers
who use a device that doesn't support IPv6, would you?

The user CPE does not understand this
issue either and has no information that could make it the smart place to
do the decision. Plus which of the multiple CPEs would be in control?
WG] IETF Homenet WG is currently chewing on the problem of multiple CPEs
in an unmanaged environment. It's not an easy problem if you have to
design it so that it works automagically no matter how strangely it's
connected together. You may want to check it out:
http://datatracker.ietf.org/wg/homenet/charter/


Maybe if the CPEs would go back and ask for more address space, if what
they initially got ran out. But DHCPv6-PD does not really have a way to do
that. In any case no CPE implements any such thing.

WG] also not exactly true. No, most CPE won't do it automatically, but
DHCPv6 can do it. Release existing prefix, request new prefix with bigger
hint. Depending on DHCP server policy, you might even be able to do it in
the opposite order (make before break) since you can have multiple
prefixes. My hunch is that on most residential broadband setups, it's not
likely to be hitless, and most cheap plastic routers can probably only do
it via a reboot after you reconfigure it to ask for more space in the
hint, but it's doable. See above recommendation for homenet if you want it
to be automatic.


Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/9/15, 11:01 PM, Lorenzo Colitti lore...@colitti.com wrote:


No, the premise is that from a user's point of view, DHCPv6-only networks
cause regressions in functionality compared to IPv4-only or dual-stack
networks. For example: IPv4 apps cannot be supported at all due because
464xlat cannot be made to work, and functions such as tethering cannot be
implemented because there are no IP addresses to assign to downstream
devices.

Implementing IPv6 NAT can resolve some but not all of these regressions
(for example, IPv4 apps still cannot be supported). Thus, attempting to
operate on DHCPv6-only networks a) will create pressure to implement IPv6
NAT, which causes lots of issues like application complexity, battery life
issues due to keepalives, etc. b) impose user-visible regressions even if
we do implement IPv6 NAT.

From a user's point of view, that's just a bad deal, especially since
IPv4-only networks, dual-stack networks, and IPv6-only networks using
SLAAC
do not have any of those issues. Stateless DHCP and stateful DHCPv6 PD
have
none of those issues, either. If we really need stateful addressing, then
we should statefully assign prefixes, not single addresses.

WG] ok, I *finally* understand the distinction you're making here, despite
the weird way you're making the argument. You're equating DHCPv6-only with
single stack IPv6, which is odd, because you're simultaneously waving
away concerns about android not working on IPv6-only networks because it
won't be able to get addresses by saying that you assume that no one is
turning off IPv4 on their network tomorrow since that'll break lots of
other things.

The reality is that this whole argument is needlessly conflating multiple
things in a way that isn't helpful, so I'm going to try to break this into
pieces in order to make forward progress and try to get us away from what
is devolving into a debate that is equal parts religion and kool-aid
drinking contest among IPv6 übernerds.

1) there are *dual stack* networks out there that happen to support IPv4
and IPv6 via DHCP only (I.e. No SLAAC). This is a fact, and you may not
like it, but there's simply no way that you're going to be able to change
it in 100% of the situations.
Most of the folks involved in this discussion are asserting that Android
needs to support those so that the things that can work over IPv6, even
with just a single address, will.

2) on a dual stack network, when the device gets fewer IPv6 addresses than
it wants/needs, it can continue using the same solution it uses on an IPv4
network, even if it's a sub-optimal NAT-based solution. Having a single
IPv6 address is still a net improvement over where we are today, where
100% of the traffic has to be on IPv4 and probably behind multiple layers
of NAT.

3) 464xlat being broken is a non-issue on a dual-stack network, since it
is expressly designed to act as a shim for IPv4-dependent apps on an
IPv6-only network.

4) At some point in the future, there will be IPv6-only networks.
At that time, Android will no longer be able to rely on IPv4 as a fallback
mechanism, and if it can only get one address, that will break things.
Definitely a problem, but not necessarily one that has to be solved
immediately, since anyone doing an IPv6-only network today already knows
that they need to make a lot of allowances for transition mechanisms and
other things to prevent breakage, or are using IPv6-only in tightly
controlled situations where there is no breakage because they can ensure
100% IPv6 support among the things using the network.

5) there are multiple possible ways for a device to get multiple IPv6
addresses if it needs them, including DHCPv6 with multiple IA_NA requests,
a DCHPv6-PD request, SLAAC, or some sort of bridging that allows multiple
virtual interfaces to use the same physical interface, such as the simple
type of hypervisor networking that allows multiple VMs to get DHCP
addresses assigned from the same network.

So what this means is that there is a draft to be written about the need
for multiple address support on IPv6 networks for mobile devices,
enumerating the ways that they use those multiple addresses, and how it
differs from today's IPv4-only or dual-stack implementations, along with a
big discussion on the breakage that can happen on IPv6-only networks if a
device can't get the addresses it needs. It is a fool's errand to assume
that we can dictate one and only one solution to #5 (regardless of one's
perceived influence and market power), so the best we can do is to
document the preferred one(s) and hope that we've made a good enough case
or made them easy enough to use that the majority of network operators do
support them.
Sunset4 is the right place for that draft, so let's discuss it at the next
IETF.

However, the spectre of #4 does NOT mean that DHCPv6 is unusable because
it would break things today on a dual-stack network, so you need to stop
trying to imply that, and stop trying to optimize for use cases that you

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 2:32 AM, Lorenzo Colitti lore...@colitti.com wrote:

I'd be happy to work with people on an Internet draft or other
standard to define a minimum value for N, but I fear that it may not
possible to gain consensus on that.

WG] No, I think that the document you need to write is the one that
explains why a mobile device needs multiple addresses, and make some
suggestions about the best way to support that. Your earlier response
detailing those vs how they do it in IPv4 today was the first a lot of us
have heard of that, because we're not in mobile device development and
don't necessarily understand the secret sauce involved. This is especially
true for your mention of things like WiFi calling, and all of the other
things that aren't tethering or 464xlat, since neither of those are as
universally agreed-upon as must have on things like enterprise networks.
I'm sure there are also use cases we haven't thought of yet, so I'm not
trying to turn this into a debate about which use cases are valid, just
observing that you might get more traction with the others.


Asking for more addresses when the user tries to enable features such as
tethering, waiting for the network to reply, and disabling the features if
the network does not provide the necessary addresses does not seem like it
would provide a good user experience.

WG] Nor does not having IPv6 at all, and being stuck behind multiple
layers of NAT, but for some reason you seem ok with that, which confuses
me greatly. The amount of collective time wasted arguing this is likely
more than enough to come up with cool ways to optimize the ask/wait/enable
function so that it doesn't translate to a bad user experience, and few
things on a mobile device are instantaneous anyway, so let's stop acting
like it's an unsolvable problem.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
--


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/9/15, 11:06 PM, Lorenzo Colitti lore...@colitti.com wrote:


Based on the facts, you could could just as well say that Apple is trying
to advance the state of the art by refusing to provide suboptimal 464xlat
and insisting instead that developers support IPv6-only networks as
first-class citizens:

https://twitter.com/dteam69/status/608036976990797824

WG] I have suggested before that google needs to do the same thing with
their app developers. Since you believe that your market power makes you
able to influence the way that people deploy IPv6 (i.e. Not using DHCPv6
because you refuse to support it), perhaps it's time to wield that power
to move the needle on IPv6 use in the app community instead of telling
network operators that are deploying IPv6 that they're doing it wrong?

By the same token, you could argue that not supporting statful DHCPv6
address assignment advances the state of the art by trying to avoid
slipping back into a one-address-per-device-NAT-required world.

WG] or you could argue that not supporting stateful DHCPv6 blocks IPv6
deployment by preventing it from being used on networks where it is
otherwise available on applications that are perfectly happy to have one
IPv6 address. That's a lot of traffic that ends up going to the NAT for no
good reason.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 9:13 AM, Baldur Norddahl baldur.nordd...@gmail.com wrote:

What standard exactly requires my router to be able to snoop a DHCP-PD to
create routes dynamically? That was left out and one solution is the one
we
use.

WG] We use this in cable-land, so it's definitely documented in the DOCSIS
standards. Not sure it exists anywhere in the IETF standards, and so YMMV
on which platforms do and do not support it.

Thanks,
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[George, Wes]

From: Lorenzo Colitti lore...@colitti.commailto:lore...@colitti.com
Date: Wednesday, June 10, 2015 at 11:21 AM
To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com
Cc: NANOG nanog@nanog.orgmailto:nanog@nanog.org
Subject: Re: Android (lack of) support for DHCPv6

I don't think it's a good plan to implement stateful DHCPv6 now and postpone 
the solution of the problem until IPv4 goes away many years from now. By then, 
a lot of water will have flowed under the bridge by then, and a lot of 
one-address-only networks will have been deployed and have moulded industry 
thinking.

So, much as it pains me to stand in the way of IPv6 adoption - and you should 
how much I've tried to do on that front - I think that that wide deployment of 
one-address-per-device IPv6 might actually do more harm than good, and I expect 
that many operators who are going to require stateful DHCPv6 addressing are 
going to use it for one-address-per-device IPv6.

I really think it's better if we get this right now, not kick the can down the 
road. That means we as an industry need to find a solution for IPv6 deployment 
in university/enterprise networks that does not devolve into 
one-address-per-device IPv6, *before* one-address-per-device IPv6 becomes 
universally implemented and usable.

WG] I wasn't suggesting kicking the can. I agree that we need a solution, and 
getting started on it now so that the guidance and potential solutions are 
available as soon as possible is the right plan, because it reduces our 
potential reliance on IPv4 as a fallback for those things that need multiple 
addresses today. However, I think you're going to have a lot of trouble 
building consensus for your view that the right response is to try to 
completely block one-address-per-device IPv6 deployment by any means possible, 
and I think you're going to have even less success actually doing it, given 
that most other devices have already built support for it.
Turning off IPv4 on a dual-stack network is a major change, as complex (or 
more) than deploying IPv6 to start with, especially if you haven't been focused 
on getting everything using IPv6 so that it's not dependent on IPv4, not to 
mention those unpredictable users. So I don't think it's unreasonable to expect 
that some changes to the existing IPv6 deployment will be necessary to support 
such a thing, and therefore I disagree with your assertion that allowing 
one-address-per-device in the short term will lead to unsolvable problems 
later, due to inertia or otherwise. It's also not guaranteed that everyone 
doing stateful DHCPv6 will limit devices to one address, so we need to be a bit 
careful with the prognostications of universal doom.

Rhetorical question: given the growing evidence that IPv6 is often lower 
latency than IPv4, and Google's heavy focus on improving performance for user 
experience (page load times, SPDY, etc) especially in the mobile space, how 
long do you think you'll really be able to justify not supporting IPv6 on a 
subset of deployments to avoid the risk of future tragedy before you're 
overruled by the potential to shave off a few more ms of latency?

Thanks,
Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
--


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[George, Wes]

From: Ted Hardie ted.i...@gmail.commailto:ted.i...@gmail.com
Date: Wednesday, June 10, 2015 at 6:09 PM
To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com
Cc: Doug Barton do...@dougbarton.usmailto:do...@dougbarton.us, 
nanog@nanog.orgmailto:nanog@nanog.org 
nanog@nanog.orgmailto:nanog@nanog.org
Subject: Re: Android (lack of) support for DHCPv6


I saw your response, but creating a hypervisor-equivalent network stack inside 
Android didn't seem particularly easy to me.  This may be, however, because 
I've mostly dealt with OVS-style approaches in the past few years and my 
calibration is off. If you have pointers to implementations that are for mobile 
devices, I'd be happy to be educated.

WG] I was merely observing that bridging so that multiple virtual 
interfaces/devices can share the same interface and get their own addresses is 
a solved problem generically. From what I can see with KVM, it involves 
creating a bridge interface or group, and bridging both the physical interface 
and any virtual interfaces into it, and then standing back. Doesn't seem 
obvious to me that it requires an entire hypervisor-equivalent network stack to 
get this one fairly limited feature, and I'm not aware of any mobile 
implementations, but it does seem to me that its presence in Linux makes it 
something we shouldn't dismiss out of hand when exploring solutions to this 
problem given Android's Linux roots - At it's core, it's still a 
general–purpose computer with a set of network interfaces. I'm not an expert on 
either Android's networking stack nor Linux's, nor hypervisors, but I have a 
hunch if this was allowed to move through the existing Android feature 
development process, we might find some folks that are and can tell us whether 
this is doable as an alternative to DHCP–PD or SLAAC on networks that generally 
adhere to the one address per device rule.

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 5:27 PM, Ted Hardie ted.i...@gmail.com wrote:

... and this argument has been refuted by the word bridging.


​To repeat Valdis' question:​

​And the router knows to send to the front address to reach the back
 address, how, exactly? Seems like somebody should invent a way to
assign a
 prefix to the front address that it can delegate to things behind it.
:)​

WG] I made reference to it in a previous message, but since the question
was repeated, I'll assume that was missed and repeat the answer. The
hypervisor folks seem to have figured this out so that it just works
without NAT, using virtual interfaces that have their own unique MAC
addresses so that they look like unique hosts to the network/DHCP server.
I'm using it on my FreeNAS (BSD) box at home with jails, and KVM supports
it, so chances are it wouldn't even be that hard to incorporate into
Android.

Thanks
Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: AWS Elastic IP architecture

[George, Wes]

On 5/31/15, 3:11 PM, Owen DeLong o...@delong.com wrote:

if they said “We have a plan, and it will take X amount of time”, I would
respect that.

If they said “We have a plan and we’re not sure how long it will take”, I
would continue to poke
them about sooner is better than later and having a target date helps
people to plan.

“We don’t think IPv6 matters and we aren’t announcing any plans to get it
implemented or any
date by which it will be available”, on the other hand, being what they
have actually repeatedly
said to me until very recently, not so much.

Now, they’re saying (essentially) “We think IPv6 might matter, but we
aren’t announcing
any plans to get it implemented or any date by which it will be
available” .  To me, this
is still a problematic situation for their customers.

At the risk of feeding the troll...

This isn't just an AWS problem.

All Compute Engine networks use the IPv4 protocol. Compute Engine
currently does not support IPv6. However, Google is a major advocate of
IPv6 and it is an important future direction.
https://cloud.google.com/compute/docs/networking


The foundational work to enable IPv6 in the Azure environment is well
underway. However, we are unable to share a date when IPv6 support will be
generally available at this time.

http://azure.microsoft.com/en-us/pricing/faq/


This is only marginally better, as it acknowledges that it's important,
but still has no actual committed timeline and doesn't even reference any
available ELB hacks.

Anyone else want to either name and shame, or highlight cloud providers
that actually *support* IPv6 as an alternative to these so that one might
be able to vote with one's wallet?


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: BCOP appeals numbering scheme -- feedback requested

[George, Wes]

On 3/12/15, 7:48 PM, Owen DeLong o...@delong.com wrote:


Then, just like the RFCs, maintain the BCOP appeal numbering as a
sequential monotonically increasing number and make the BCOP editor
responsible for updating the index with the publishing of each new or
revised BCOP.

Note, IMHO, a revised BCOP should get a new number and the previous
revision should be marked “obsoleted by X” and it’s document status
should reflect “Obsoletes , , and ” for all previous
revisions. The index should probably reflect only BCOPs which have not
been obsoleted

A note of caution:
Please don't exactly replicate the RFC series's model where the existing
document can only be updated by new documents but is not always completely
replaced/obsoleted such that the reader is left following the trail of
breadcrumbs across multiple documents trying to figure out what the union
of the two (or 3 or 14) current documents actually means in terms of the
complete guidance. If what you're suggesting is actually a full
replacement of the document so that the new version is complete and
standalone, I think that's better, but really I don't understand why these
can't be more living documents (like a Wiki) instead of just using the
server as a public dropbox for static files. The higher the drag for
getting updates done, the more likely they are to go obsolete and be less
useful to the community.

Thanks,

Wes George


Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: draft-ietf-mpls-ldp-ipv6-16

[George, Wes]

On 2/19/15, 2:27 PM, Mark Tinka mark.ti...@seacom.mu wrote:

Getting IPv6 support in LDP is one thing.

This is one document that we need to keep track to know what MPLS
applications currently running off of LDPv4 still need to be ported to
run over LDPv6:

http://tools.ietf.org/html/draft-george-mpls-ipv6-only-gap-04


The document has come out the other side of the IETF sausage grinder now:
https://tools.ietf.org/html/rfc7439

Unfortunately, it's just a list of the gaps.
It is worth leaning on your vendors of choice to ensure that they have
people focused on addressing these issues, as not all of them have
volunteers to write the documents necessary to close those gaps yet.

Thanks

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: [request]: host a probe for v6 measurements

[George, Wes]

We've seen 3 or 4 recent presentations of some new measurement project
that requires deploying yet another set of dedicated probes. While I'm
generally supportive of measurement attempts, I'll ask the same question
that was asked then:

Why not use RIPE Atlas?

https://atlas.ripe.net/docs/udm/


Wes George



On 1/19/15, 8:33 AM, Bajpai, Vaibhav v.baj...@jacobs-university.de
wrote:

Dear NANOG,

We are currently looking for volunteers in US with native IPv6 lines
to help us in our v6 measurement research.

——-- Background
We are interested in measuring IPv6 performance from home. As part
of the LEONE project [1], we have developed measurement tests that
compare performance over IPv4 and IPv6 to: a) Dual-stacked websites
and b) YouTube content delivery network (in collaboration with Aalto
University). The tests comes bundled with a LEONE SamKnows probe.

[1] http://www.leone-project.eu

We currently have ~25 Vantage points (VP). Each VP runs a Leone
SamKnows probe. The google map [2] shows where these probes are
deployed. As you can see the VP sample is too small (nothing in
North America)

[2] http://goo.gl/TL4woP


——-- Request:
If you receive native IPv6 at home (or know someone who does), it
would be great if you can host a LEONE SamKnows probe for us. The
probe will run standard SamKnows tests [3] and our IPv6 tests.

[3] https://www.samknows.com/tests-and-metrics

We prefer measuring from home networks, but are also open to
deploying probes within research/academic networks, business
lines, or operators labs.


 Action:
Let me know if you’re interested, and I can share details on how to
get the probe to you. We only have limited number of LEONE SamKnows
probes. We will process the requests on first come first serve basis.



 Research Impact.
a) Measuring YouTube from Dual-Stacked Hosts
  Saba Ahsan, Vaibhav Bajpai, Jörg Ott, Jürgen Schönwälder
  Passive and Active Measurement Conference (PAM 2015),
  New York, March 2015.

b) Measuring TCP Connection Establishment Times of Dual-Stacked Web
Services
  Vaibhav Bajpai, Jürgen Schönwälder
  9th International Conference on Network and Service Management, (CNSM
2013)
  Zürich, October 2013.


8——-- Thanks.
Thank you so much for helping us in our research activity.


Best, Vaibhav

=
Vaibhav Bajpai

Research I, Room 91
Computer Networks and Distributed Systems (CNDS) Lab
School of Engineering and Sciences
Jacobs University Bremen, Germany

www.vaibhavbajpai.com
=


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Comcast thinks it ok to install public wifi in your house

[George, Wes]

On 12/12/14, 1:33 AM, Javier J jav...@advancedmachines.us wrote:

What stops someone from going down to the center of town, launching a
little wifi SSID named xfinitywifi and collecting your customers usernames
and passwords?

WG] nothing. But then again, the same argument can be made for *any*
wireless network that does authentication via a portal, because it becomes
a standard phishing spoof problem that is dependent on how well you
imitate the portal in question. Not really a comcast-specific problem,
though this blog demonstrates exactly what you suggest:
https://blog.logrhythm.com/security/xfinity-pineapple/

Hotspot 2.0 is intended to help with this problem to some extent.
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/service-
provider-wi-fi/white_paper_c11-649337.html

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Comcast thinks it ok to install public wifi in your house

[George, Wes]

On 12/11/14, 1:43 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca
wrote:


BTW, it isn't just the electricity, but also climate control and
location which the subscriber provides for free.  Comcast need not rent
space on poles and need not buy more expensive weatherized equipment
that goes outdoors.

WG] In most cases your second assertion is not accurate, because the one
doesn't eliminate the need for the other. The pole/strand/vault mounted
and weatherized equipment is also quite a bit more powerful and has
external antennas so that it has better range, and likely has had some RF
engineering done to provide some reasonable envelope of contiguous
coverage between APs. The majority of these home GWs are unlikely to be a
real alternative to that sort of deployment for folks walking/driving past
your house even in the best case scenario where the AP is optimally
located and nearly every home on the block is participating and the houses
are very close to one another and to the street. This is still
fundamentally the same AP that may or may not have enough signal strength
to provide consistent performance in all areas of the inside of a home
(dependent on things like the location of the AP, the size  construction
of the home, other interference, etc etc). Their intended use is to give
access to visitors in your house and/or yard without you needing to set up
a dedicated guest network or giving them your wifi password.

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Comcast thinks it ok to install public wifi in your house

[George, Wes]

On 12/11/14, 3:58 PM, Jay Ashworth j...@baylink.com wrote:


Alas, I cannot accept George's assertion
WG] well, perhaps you can accept Wes's assertion instead. ;-)

In residential areas (non-multi-unit),
this is only going to help out *Comcast subscribers*.  If you have random
visitors over, it won't help them, as they can't get authed to the
service.
WG] Given an average Comcast service area, there is a nonzero chance that
visitors are Comcast customers as well. Given that there are multiple such
service areas, to the tune of 19M+ subs, this is true even if the visitors
aren't local. The chances go up if the AP will accept roaming credentials
from customers of other members of the Cable Wifi initiative (though I am
not sure that this is the case on the resi APs).

And it doesn't let you help your neighbors for the same reason: if they
have their own creds for it, then they don't need your AP since they have
one.
WG] unless they're over visiting you and would like to use WiFi to avoid
using metered (or slow, or both) mobile data, or your AP's signal happens
to be stronger from that one corner of their house/yard than theirs, or
theirs has had its magic smoke released, or...


No, I'm having a hard time figuring out what the use case *is* for this
service
as deployed against *residential* hardware, myself...
WG] it's a feature or additional service that can be offered to customers
to use if they find it useful (or not if they don't), done with the
capabilities of the existing hardware, so the bar for use case is pretty
low.

Wes (not) George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ARIN's RPKI Relying agreement

[George, Wes]

On 12/4/14, 10:35 AM, Andrew Gallo akg1...@gmail.com wrote:

Honestly, that's what I'm trying to figure out as well.  In my informal
conversations, what I got was that lawyers read the agreement, said 'no,
we wont sign it' and then dropped it.  If specific legal feedback isn't
making it back to ARIN, then we need to start providing it, otherwise,
the agreement will stand.

For my part, I have had discussions with ARIN's internal legal council and
other staff about our specific concerns and how to address them, and
intend to continue doing so, as I agree that this won't get solved if we
just say unacceptable and drop the subject. That said, this is harder to
manage because it doesn't fall into the existing ARIN policy development
process, so the community doesn't have as direct of a voice on changes to
the policies. I can't just submit a policy proposal to change how ARIN
words its RPA, who is bound by it, and how ARIN provides RPKI services.
Those are operational matters, implemented by the staff, governed by the
board, who is informed by their legal council and staff. That is part of
the reason why I brought some of the issues to the NANOG community, since
interaction with ARIN board members and staff is what's necessary to make
sure the concerns are addressed, and thus it benefits from wider
discussion.

I'll try to go through your survey as well.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ARIN's RPKI Relying agreement

[George, Wes]

On Thu, Dec 4, 2014 at 7:51 AM, Bill Woodcock wo...@pch.net wrote:

  All the specific legal feedback I’ve heard is that this is a
  liability
  nightmare, and that everyone wants ARIN to take on all the
  liability, but
  nobody wants to pay for it.

WG] Has there been any actual discussion about how much nobody would
have to pay for ARIN (or another party) to fix the balance of liability
and provide a proper SLA that led to no, I don't want to pay for that
responses from those who are expressing the concern, or is this just
conjecture on your part? I know that despite being fairly vocal on the
matter, I've not been party to any such discussion, though I know that
ARIN fees and what services they provide for those fees is an ongoing
discussion in other forums.
The problem with free services is that often you get what you pay for when
it comes to support, warranty, etc. There are plenty of models where you
take something free, say FOSS, and then pay someone (Red Hat, ISC) to
support it in order to manage the risk associated with putting it in the
middle of your business-critical system. It gives you some determinism
about what happens when it breaks or you need a feature, and recourse when
it goes pear-shaped. I think there's room for discussion around how much
an SLA-backed RPKI service might be worth to its potential customers,
given its ability to either protect or badly break global routing.


On 12/4/14, 11:33 AM, Jay Ashworth j...@baylink.com wrote:


Lawyers believe that their job is to tell you what not to do.

Their *actual job* is to tell where risks lie, so that you can make
informed business decisions about which risks to take, and how to
allow for them

WG] FWIW, I believe that my lawyers did their actual job. But as I said
in my presentation, the combination of technical fragility and liability
risk I incur if it breaks in a way that impacts my customers led me to
decide that I'm not yet willing to bet my continued gainful employment on
Route Origin Validation working well enough that the benefit of having it
outweighs the risks.
INAL, YMMV, void where prohibited, caveat lector, of course.
Fixing the liability issues certainly removes one barrier to entry, but
it's not the only one, and the technical issues are being worked in
parallel.


Wes George


Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ARIN's RPKI Relying agreement

[George, Wes]

On 12/4/14, 1:13 PM, John Curran jcur...@arin.net wrote:

I am happy to champion the change that you seek (i.e. will get it
reviewed
 by legal and brought before the ARIN Board) but still need clarity on
what
 change you wish to occur -

A) Implicit binding to the indemnification/warrant disclaimer
clauses
   (as done by the other RIRs)

B) Removal of the indemnification  warranty disclaimer clause

 I asked this directly during your NANOG presentation, but you did not
respond
 either way.

WG] I deferred because I am not a lawyer and am not empowered to speak
anything more than my opinion on the matter. I believe that the more
useful response to your question came during the ARIN members' meeting
post-NANOG, where Rob Seastrom suggested at the mic that rather than a
bunch of engineers and policy wonks playing armchair lawyer and guessing
at what will make the actual lawyers happy, that we should organize a
separate meeting involving:
- the ARIN board
- ARIN legal counsel and other relevant ARIN staff
- legal representatives from as many of the operators and others
expressing concern over this as appropriate,
- along with a few of the technical folks to help deal with the
interaction between the technical and the legal

and use it to discuss the issues in order to come up with something
better.

(One can easily argue that best practices require multiple connections
or service providers, but that is the same with best practices for RPKI
use requiring proper preferences to issues with certification data...)

WG]  So how would I as an ARIN member go about getting a redundant RPKI
provider? I'm uncomfortable being single-homed to ARIN since that seems
contrary to best practices.

Also: Most SPs provide an SLA to their customers that serves as a balance
to contractual liability weasel words.

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ARIN's RPKI Relying agreement

[George, Wes]

On 12/4/14, 1:34 PM, Bill Woodcock wo...@pch.net wrote:


I’ve asked a lot of people, “Would you be willing to pay ARIN for RPKI
services,” and the answer has always been “no.”  Until I get a “yes,”
it’s hard to put a number (other than zero) on how the market values
RPKI.

WG] well, if it wasn't clear from my previous message, you've gotten a
yes, but it's a qualified yes, and the timeframe, as well as what I'm
paying for, matters.
We need to put some daylight between how the market values RPKI and
whether RPKI is ready for wide-scale deployment and what the market
expects from ARIN as a service provider for a critical piece of that
system when it's in wide-scale deployment.

You can see multiple folks expressing concern about other aspects of RPKI
beyond ARIN's RPA and liability. Those problems have to be solved before
we can have a real discussion about how the market values RPKI, because
prior to that it's simply not ready for wide-scale deployment.
Additionally, we have a catch-22 in that most of RPKI's benefit is not
realized until there are enough prefixes signed and enough large networks
validating signatures and dropping invalid announcements, which means the
incentive for early adopters is hard to quantify. In other words, the
benefits of deploying RPKI that we have to use to justify the costs,
whether it's increased ARIN fees or the hardware, complexity, and
headcount costs associated with deploying and maintaining it, cannot be
realized yet.
So, the only thing I know to do is to make sure that I'm working these
issues in parallel so that we don't remove one barrier to entry only to
crash into the next one.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ARIN's RPKI Relying agreement

[George, Wes]

On 12/4/14, 2:34 PM, Andrew Gallo akg1...@gmail.com wrote:


Am I correct in thinking that the SIDR work going on in the IETF takes the
registries out of the real-time processing of route
authentication/attestation?
WG] no, but they're at least discussing ways of making the dependencies
less fragile and more scalable (e.g. Eliminating rsync).


Is RPKI a stop-gap while we wait for full path validation?  Should we be
focusing our energies in that area?
WG] Path Validation is a completely separate pig, one which may require
significantly more thrust to achieve escape velocity when compared with
Origin Validation. Origin Validation isn't a stop gap, as much as it is an
incremental step that Path Validation builds on to provide more additional
protection that Origin Validation alone cannot provide. They're intended
to coexist, not replace.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: ARIN's RPKI Relying agreement

[George, Wes]

On 12/4/14, 2:19 PM, Sandra Murphy sa...@tislabs.com wrote:


Which begs the question for me -- ARIN already operates services that
operators rely upon.  Why are they different?  Does ARIN run no risk of
litigation due to some perceived involvement of those services in
someone's operational outage?

WG] I'm hard-pressed to come up with a case where packets stop flowing or
flow to the wrong party because whois is down. *Maybe* you can make that
case for reverse DNS since lots of anti-spam/anti-spoof relies on
forward/reverse DNS agreement, but that doesn't affect routing. RPKI ups
the ante considerably. I believe ARIN when they say that the liability
risks are higher for this.

Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

IPligence contact?

[George, Wes]

if anyone has a live-person contact at geolocation provider IPligence
(http://www.ipligence.com/) and can hit me up off-list, I would appreciate
it.

Thanks,


Wesley George
Time Warner Cable


Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Prefix hijacking, how to prevent and fix currently

[George, Wes]

On 8/28/14, 11:28 PM, Mark Andrews ma...@isc.org wrote:

   The long term solution is to deploy RPKI and only use
   transits which use RPKI. No RPKI support = no business.
   Additionally make RPKI a peering requirement.

WG] So should we ask for that before, or after we get everyone to roll out
IPv6 everywhere by voting with our wallets?

*ducks*

On 8/28/14, 11:24 PM, Fred Baker (fred) f...@cisco.com wrote:

Are providers that neighbor with them implementing RPKI?
If not, complain to the folks not indicating RPKI and therefore accepting
a hijacked prefix.

WG]

%s/RPKI/inbound route filtering on downstream customers/g

There, FTFY

Tarun, other than directly contacting the originator, I recommend that you
complain to their upstream provider(s) (the neighboring ASN(s) in the
AS-Path) that they are accepting routes from their customer that they
shouldn't be, include proof that you own the block they are announcing,
and ask them to apply a prefix filter. Yes, this presupposes that you can
find valid contact info in whois or peeringdb, but it's the best we've got
right now.

RPKI isn't likely to fix this anytime soon, because it's mostly not
deployed where it needs to be to affect this problem. And just like
inbound route filtering and lots of other protective security measures,
[1, 2] and eating your vegetables, and getting more exercise, most folks
agree that it would help, but it's only useful with wide deployment, which
mostly needs to happen on everyone else's network, and those things all
have an additional cost (time, money, or both) to deploy and maintain. The
unfortunate thing is that RPKI arguably takes more work than the others,
with a much longer time-horizon to see benefit during the incremental
deployment period.

Wes George

[1] https://www.routingmanifesto.org/manifesto/
[2] http://tools.ietf.org/html/draft-ietf-opsec-bgp-security

Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Prefix hijacking, how to prevent and fix currently

[George, Wes]

On 8/29/14, 9:08 AM, Randy Bush ra...@psg.com wrote:


considering that measured rpki registration (which has a very tragic
side) is ten time ipv6 penetration, i think we ask for rpki first.

WG] I guess I should know better than to ask rhetorical questions on
NANOG, lest I get an answer.
The horse race to determine the fastest lame horse is a rather boring one
to watch, but unless you're counting how many ASNs have IPv6 allocations
(whether they're using them or not) as a measure of IPv6 penetration,
counting RPKI registrations as penetration doesn't lead to a useful
comparison. Number of ASNs doing *validation* and discarding invalid
routes (especially among top transit N ASNs by reach) would be far more
telling as a measure of penetration, since it directly impacts RPKI's
relative effectiveness at preventing hijacks such as the original poster
was experiencing.



but keep shoveling.  it's a good week for twt.
WG] Randy, if you're going to try to poke me in the eye about an outage in
lieu of a snappy comeback, the least you could do is get my company's name
right. ;-) It'll be in the stupidly long disclaimer at the bottom of this
message for future reference, but it's in the first sentence, so you don't
even have to read the whole thing.

Wes


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Time Warner outage?

[George, Wes]

I am not cleared to give further details, but in the hopes of providing a
little more accurate info, I can point you at the following blog post
http://www.twcableuntangled.com/2014/08/twc-identifies-cause-of-internet-ou
tage/


Thanks,

Wes George


Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Ars Technica on IPv4 exhaustion

[George, Wes]

On 6/21/14, 3:20 PM, Frank Bulk frnk...@iname.com wrote:

Donley said that Cablelabs moved to a new hosting provider that (at that
time) did not support IPv6.

Www.cablelabs.com does have a , it's just that cablelabs.com doesn't.
Unfortunately all too common. We're also leaning on them to be more
complete in their IPv6 support.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Help with Confederation-RR-MPBGP

[George, Wes]

On 6/18/14, 12:31 PM, Philip Lavine source_ro...@yahoo.com wrote:


I guess my question is, is it best practice to confederate or use a route
reflector

Basically I want to know what an ISP would do, not a test in a LAB.

One data point that you may find useful: If you find out later that you’ve
chosen incorrectly the first time around, it is FAR easier to change
*from* RRs *to* Confeds than it is to do the opposite. The AS migration
tools that you’d normally use to handle moving routers from one ASN to
another don’t work to migrate routers from a confed ASN to a normal iBGP
ASN setup, probably because the BGP machinery doesn’t know what to do with
the union of the changes those things make to BGP’s default behavior, so
you’re stuck with trying to find the least bad flag day way to handle
renumbering ASNs out of a confed. Doing it without major traffic impact is
pretty difficult since most of the options involve nuking BGP and
rebuilding it to punt routers from one ASN to another, and doing this on
multiple routers simultaneously in order to minimize the time when BGP is
offline on multiple devices due to ASN mismatches. Size of network of
course matters when considering whether this is really a potential issue
for you, but since you’re asking in terms of what an ISP would do vs what
works in a lab, considering large scale rather than today’s scale when
determining the exit strategy is pretty important.


Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Ars Technica on IPv4 exhaustion

[George, Wes]

On 6/18/14, 4:09 PM, Owen DeLong o...@delong.com wrote:


Now, consider DVRs, BluRay players, Receiver/Amplifiers, Televisions,
etc. where there are, currently, no IPv6 capable choices available to
the best of my knowledge.

I think this thread exemplifies a problem among the IPv6 early adopters
who like to whine about the rate of adoption: the best of (y)our knowledge
is likely stale, because things are changing constantly. People are fond
of trotting out the same arguments they’ve been making for years about who
is at fault for IPv6’s weak adoption without actually verifying that the
issue still exists or is as bad as last time they looked i.e. ISP
deployment levels, level of support in equipment, etc. Not saying that all
the problems are solved, or that they didn’t contribute to the issue in
the past, but the “guy walks into a big box store” tale of woe might be a
bit exaggerated now.
The problem now is that because IPv6 isn’t a feature most customers ask
for, a product’s support for it (or lack thereof) is not consistently
published in the vendor specs.

For example: in ~September 2013 I was pleasantly surprised to find (via
some colleagues observing it in the UI) that a number of current Sony TVs
and BluRay players do in fact support IPv6, but at the time, it wasn’t
listed as a feature on their model info on the site. Haven’t checked to
see if it’s there now.
@sonysupportusa on twitter has been helpful when asked questions about
specific models’ IPv6 support, but as I told them, there’s really no
substitute for having the info on the site. It’s not complete *cough* PS4
*cough* but they’re getting there.
Similarly, Belkin’s home routers appear to support IPv6, but that doesn’t
appear in the specs or features list on their site when I just checked it.

I support a recommendation to consumer retailers to start requiring IPv6
support in the stuff that they sell, but unfortunately I don’t have very
good data on how large of a request that actually is.

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
---


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[George, Wes]

On 5/12/14, 10:07 AM, Owen DeLong o...@delong.com wrote:


On May 12, 2014, at 6:02 AM, Nick Hilliard n...@foobar.org wrote:

 On 10/05/2014 22:34, Randy Bush wrote:
 imiho think vi hart has it down simply and understandable by a lay
 person.  http://vihart.com/net-neutrality-in-the-us-now-what/.  my
 friends in last mile providers disagree.  i take that as a good sign.

 Vi's analogy is wrong on a subtle but important point.  In the analogy,
the
 delivery company needs to get a bunch of new trucks to handle the
delivery
 but as the customer is paying for each delivery instances, the delivery
 company's costs are covered by increased end-user charges.

Two words nuke your suggestion here: Amazon Prime

Amazon Prime isn’t a flat-rate delivery service for the delivery company,
else it’d be called FedUPS Prime. It’s a flat rate shipping subscription
for *Amazon*, and is likely a loss leader to ensure better stickiness of
Amazon’s potential customers. They may have a great deal of negotiating
leverage on their delivery partners to reduce their shipping costs, and
the sheer volume of Amazon warehouses mean that they can take advantage of
proximity to reduce costs further (like a CDN), but I haven’t seen
anything implying that they’ve been successful in negotiating a contract
that is insensitive to the *amount* of items being shipped.

Wes George


This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: OpenNTPProject.org

[George, Wes]

I’ll note that this is less than 140 chars, and therefore fits nicely in a
tweet.

If you’re on twitter, Signal boost the PSA, please.

My edited example: https://twitter.com/wesgeorge/status/435404354242478080

Wes George



On 2/16/14, 10:03 PM, Kate Gerry k...@quadranet.com wrote:

add these to your ntp.conf
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery



Anything below this line has been added by my company’s mail server, I
have no control over it.
---



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

Re: Verizon FIOS IPv6?

[George, Wes]

On 1/7/14, 11:10 PM, Adam Rothschild a...@latency.net wrote:

I should probably add that there was a real router plugged into the
ethernet port on the ONT, given a lack of support in the ActionTec
code ...

Interestingly, I have one of the later-generation ActionTecs, and VZ
pushed a software update to it at some point and it sprouted IPv6 config.

https://plus.google.com/u/0/+WesleyGeorge/posts/hZR5nRgKyQ4

And no, clicking ³enable² doesn¹t do anything, least it didn¹t last time I
fiddled with it.

They¹ve at least updated this page from ³later in 2012² to ³starting in
2013² but clearly that¹s still not very helpful.
http://www.verizon.com/Support/Residential/Internet/HighSpeed/General+Suppo
rt/Top+Questions/QuestionsOne/ATLAS8742.htm

Wes George

Anything below this line has been added by my company¹s mail server, I
have no control over it.
---







This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

RE: What Should an Engineer Address when 'Selling' IPv6 to Executives?

[George, Wes]

 From: Matthew Kaufman [mailto:matt...@matthew.at]

 They suggest that IPv4 support is needed *in conjunction with* IPv6
 support for 5-8 years.

 That's a long time if you're developing software... so, basically, no...
 no cost or effort saving if you were to do this work today. In fact, 2x
 the effort if you were to start today.

 So again, why try to sell it to the engineers that way? Either sell it
 as 1) If you don't start doing a lot more work now you'll be screwed at
 the transition or 2) You should just wait until you can single-stack on
 IPv6.
[WEG] snip

 The point being that for some applications, *both ends* need to be on
 IPv6 before any of this complexity can go away.

 For the rest, they're just talking to web services... and until the
 places those are hosted run out of IPv4 addresses, nobody cares.

[WEG] One point to consider is that as an application/content provider, there 
is a real risk to you that the kinky middlebox (CGN, etc) that an SP puts 
between you and your customers in order to extend the life of IPv4 in their 
network will break or otherwise degrade your service in ways that you can't 
control, may not be able to test for, and may not be able to fix easily. The 
success of your business becomes dependent on that ALG, or the scale and 
performance of that box and its effect on latency and jitter. You're basically 
held hostage by the business drivers of an organization that has little vested 
interest in ensuring your specific application works, other than to ensure that 
the majority of their customers stay happy. How much do you trust $ISP not to 
negatively affect your user experience?

Fixing it requires good assumptions about all possible variations of how it 
might work in each SP and vendor implementation so that your NAT traversal code 
works across multiple layers of NAT in each direction, and that may not help if 
the performance is just bad on account of scale. This is incrementally worse 
than the status quo today, because while CGN/NAT44 is fairly common, especially 
in the mobile space, it isn't as common in networks where there is already a 
layer of NAT (eg a home ISP) thus giving you NAT444, so it's maybe not quite as 
simple as you're making it.
I'm not going to argue that this problem will magically go away if you start 
supporting IPv6 in the next feasible release, but given the IPv6 deployments 
underway in many ISPs, it seems a worthwhile thing to pursue in order to 
possibly bypass some permutations of NAT that you're not solving for today and 
attempt to remove another barrier to moving to IPv6-only and the attendant 
reductions in complexity single-stacking provides.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

RE: The Verge article about Verizon's Sandy Cleanup Efforts in Manhattan

[George, Wes]

 From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
 
  http://www.theverge.com/2012/11/17/3655442/restoring-verizon-service-m
  anhattan-hurricane-sandy
 

 hey lookie! 'free uprades'!


[WEG] Better that than we're going to replace all of this old technology with 
exactly the same stuff because that's what the standards document says to do 
like happened in the rebuilding efforts for Katrina. I remember someone 
presenting about that rebuilding effort during NANOG years ago, and I asked 
about opportunities for improvement and upgrades and was really depressed at 
the missed opportunity it represented as they confirmed that they were in fact 
laying new copper...

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

RE: Trouble accessing www.nanog.org

[George, Wes]

 From: Wessels, Duane [mailto:dwess...@verisign.com]
 Sent: Wednesday, January 04, 2012 1:41 PM
 Subject: Re: Trouble accessing www.nanog.org


 The brief problem in accessing www.nanog.org was due to numerous
 parallel
 downloads of a large video file by a single source IP address.  We have
 no reason to believe it was malicious in intent, but the offender has
 been
 blocked anyway.

[WEG] In the lovely CGN future, not only will you see this type of behavior 
(multiple pulls from the same IP) all of the time, your response to block it 
would have taken tens or hundreds of users out of service simultaneously.
/troll

Not meant to fault your response, merely to point out yet one more way that CGN 
is likely to break things where an assumption of 1 IP = 1 user/host/network 
exists.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

RE: meeting network

[George, Wes]

  o no hotel believe that we'll actually be significantly high use.
they simply can not conceive of it.  ietf, apricot, ... have
seen this time and time again

WEG] this is a problem that is quite solvable via the careful application of 
real data from past events
I assume most of these conferences can track number of unique devices seen (by 
MAC address) peak and total, show peak and average network usage BW graphs, etc.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.

RE: Found: Who is responsible for no more IP addresses

[George, Wes E [NTK]]

 -Original Message-
 From: Jay Ashworth [mailto:j...@baylink.com]
 Sent: Thursday, January 27, 2011 2:06 PM
 To: NANOG
 Subject: Re: Found: Who is responsible for no more IP addresses

 - Original Message -
  From: Brian Johnson bjohn...@drtel.com
  
  To be clear, FOX screwed this up big time, but that doesn't mean we
  all need to get out our personal/political pitchforks and run them
 out
  of town. Take your Ritalin.  :-)

 Fox didn't screw up, for a change, and Vint's quote appears in many
 other news sources.  Apparently, I'm the only one on Nanog who knows
 about this new thing called The Google.  :-)

 Thinking that Fox News is not a reputable news source is not, indeed,
 an opinion attributable *solely* to non-Republicans, and indeed, it's
 easy
 to prove in a documentary, non-partisan fashion.

[WES] Don't kid yourself, defending a reputable news organization for not 
properly checking their facts on a technical story before publishing is 
politically motivated too, especially when you try to imply that being willing 
to call out inaccurate (technical) info in the news is somehow related to 
one's political party.

The article that everyone is causing everyone to make fun of Fox news for says 
nothing about Vint.
Fox news has posted two separate articles, both of which have been factually 
incorrect.
http://www.foxnews.com/scitech/2011/01/26/internet-run-ip-addresses-happens-anyones-guess/
and
http://www.foxnews.com/scitech/2010/07/26/world-run-internet-addresses-year-experts-predict/

They at least corrected the first one - Editors' Note: An earlier version of 
this story erroneously described an IP address as consisting of four digits, 
rather than four sets of digits, and inaccurately described the IP address. 
This story has been updated to reflect the correction.
But this gem still exists in the first article: Web developers have 
compensated for this problem by creating IPv6. At least there's *probably* 
some web developers at IETF that might have had a hand in creating IPv6, so 
that one's not technically incorrect...

The second one from several months ago is still borked:
IPv4, ... the unique 32-digit number used to identify each computer, website 
or internet-connected device. ... The solution to the problem is IPv6, which 
uses a 128-digit address. So, first it was 32 digits, then it was 4 digits...

FWIW, Marketplace (on NPR) did a story the other night too. It wasn't 
necessarily incorrect, but it was so dumbed down that they managed to talk 
about IPv4 exhaustion without mentioning the words IPv4 or IPv6
http://marketplace.publicradio.org/display/web/2011/01/25/pm-internet-running-out-of-digital-addresses/

Wes George


smime.p7s
Description: S/MIME cryptographic signature

RE: Why is your company treating IPv6 turn ups as a sales matter?

[George, Wes E [NTK]]

 -Original Message-
 From: William Herrin [mailto:b...@herrin.us]
 Sent: Thursday, November 18, 2010 2:06 PM
 
 Why are your respective companies treating IPv6 turn ups as a sales
 matter instead of a standard technical change request like IP
 addresses or BGP? 
[WES] Because in most companies, sales owns the direct relationship with the
customer, so when they ask about a new feature or service, they work with
sales, and sales gets the right technical folks involved. A clarification
that is probably important here: a sales matter != extra charges for
IPv6 at least at my employer, so if you believe that is why it's being
referred to sales, I ask that you not jump to conclusions. Eventually, this
is something that can be accomplished solely through a portal like any other
technical change request, but short term, we wanted to focus on making our
IPv6 availability as wide as possible and as soon as possible. That requires
a bit more handholding, and sometimes a manual process here and there, which
involves sales. 

Sprint and Qwest, I know you're guilty.
[WES] Bill, I know that you mean well and you're just trying to push IPv6
deployment, and sometimes a little public shame goes a long way, but in the
future, before you call my company out in public with tenuous assertions
like this, please at least try to reach out to me privately to address your
perceived issue with the way Sprint is handling IPv6 rollout? It's not like
I'm hard to find, even if it's a blast message to NANOG that looks like
Will someone with IPv6 clue at Sprint contact me?
 
 How many of
 the rest of you are making IPv6 installation harder for your customers
 than it needs to be?
[WES] I guess that depends on who you talk to and their definition of hard.
Obviously you feel that there's some problem, so feel free to provide
details specific to Sprint off-list and I'll do my best to address them.

Wes George 
Token Sprint whipping boy and IPv6 mechanic
http://www.sprintv6.net



smime.p7s
Description: S/MIME cryptographic signature

RE: ipv6 bogon / martian filter - simple

[George, Wes E IV [NTK]]

This would be another alternative:
http://www.space.net/~gert/RIPE/ipv6-filters.html

Slightly more than 1 line, but the loose case would nuke a few more things than 
just filtering on 2000::/3 without requiring frequent updates. The strict case 
requires keeping after it for updates, and you'd probably be better off with 
Cymru.

Thanks,
Wes George

-Original Message-
From: Brandon Applegate [mailto:bran...@burn.net]
Sent: Monday, June 14, 2010 7:38 PM
To: nanog@nanog.org
Subject: ipv6 bogon / martian filter - simple

I mean really simple.  Like 2000::/3.  If it's not in there it's bogon,
yes ?

What I'm really asking, is for folks thoughts on using this - is it too
restrictive ?

How long until it's obsolete ?

Should be a really long time no ?

Again, just looking for some feedback either way.  Would be very nice to
have a single line ACL do this job.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
SH1-0151.  This is the serial number, of our orbital gun.




This e-mail may contain Sprint Nextel Company proprietary information intended 
for the sole use of the recipient(s). Any use by others is prohibited. If you 
are not the intended recipient, please contact the sender and delete all copies 
of the message.

RE: Quick IP6/BGP question

[George, Wes E IV [NTK]]

We've done it both ways.
We've found that there are sometimes issues with announcing IPv6 NLRI over IPv4 
BGP sessions depending on your chosen vendor and code version on both sides of 
the session. Specifically, we have seen some implementations where an 
IPv4-mapped IPv6 address (usually the IPv4 router-id or neighbor address) is 
announced as the next-hop, or a link-local address is used as the next-hop, or 
some random junk is announced as the next-hop, even with next-hop-self 
configured. All of these result in the receiving router dropping the 
announcements because it doesn't have a route to the next-hop. It's usually 
possible to work around this by using route policies to force the correct 
next-hop to be written on in/outbound announcements, and as we find it working 
improperly, we've been reporting bugs, but I thought it would be worth bringing 
this up as a caveat so that you can make sure your hardware/software of choice 
is behaving properly if you choose to go this route.
Also, I know of at least one vendor that didn't implement the converse 
functionality in CLI yet - it's impossible to configure an IPv6 neighbor 
address in the IPv4 address family in order to exchange IPv4 NLRI over an IPv6 
BGP session.

Thanks,
Wes George

-Original Message-
From: Thomas Magill [mailto:tmag...@providecommerce.com]
Sent: Monday, May 24, 2010 2:22 PM
To: nanog@nanog.org
Subject: Quick IP6/BGP question

From the provider side, are most of you who are implementing IP6
peerings running BGP over IP4 and just using IP6 address families to
exchange routes or doing IP6 peering?



Thomas Magill
Network Engineer

Office: (858) 909-3777

Cell: (858) 869-9685
mailto:tmag...@providecommerce.com mailto:tmag...@providecommerce.com


provide-commerce
4840 Eastgate Mall

San Diego, CA  92121



ProFlowers http://www.proflowers.com/  | redENVELOPE
http://www.redenvelope.com/  | Cherry Moon Farms
http://www.cherrymoonfarms.com/  | Shari's Berries
http://www.berries.com/





This e-mail may contain Sprint Nextel Company proprietary information intended 
for the sole use of the recipient(s). Any use by others is prohibited. If you 
are not the intended recipient, please contact the sender and delete all copies 
of the message.

RE: IPv6 enabled carriers?

[George, Wes E [NTK]]

-Original Message-
From: Seth Mattinen [mailto:se...@rollernet.us]
Sent: Wednesday, March 10, 2010 2:19 PM
To: nanog@nanog.org
Subject: Re: IPv6 enabled carriers?

On 3/10/10 11:00 AM, Charles Mills wrote:
 Does anyone have a list of carriers who are IPv6 capable today?

snip
Sprint wasn't on your list, but they are
rolling out native IPv6 support on all of 1239. I've been using their
6175 testbed since 2005.

~Seth

Not trying to make a big shameless plug here, but I thought I should at least 
confirm this to be true. Mostly domestic until ~mid-year, limited port 
availability in the next couple of months, more sites and port speeds available 
as the year and the rollout progresses.
www.sprintv6.net or your Sprint sales droid will have updates as they're 
available.

Thanks,
Wes
_
Wesley George
Sprint
Core Network Engineering - IP
O:703-689-7505   M:703-864-4902
http://www.sprint.net




This e-mail may contain Sprint Nextel Company proprietary information intended 
for the sole use of the recipient(s). Any use by others is prohibited. If you 
are not the intended recipient, please contact the sender and delete all copies 
of the message.