Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 3:49 PM, Jon Bane  wrote:

> Seriously, this is how you are going to respond?  You are claiming you
> know what is best for everyone and I am telling you that I know is best for
> MY network. Who are you to even begin to understand my requirement or
> presume to know them better?
>

Forgive me, I thought you were saying that you know what operating systems
need to do. If that's not what you were saying, then please ignore that
part of my reply.

RE: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Tue, 9 Jun 2015, Tony Hain wrote:


I filed a platform bug on this back in the ICS timeframe, and it still
persists. As I recall, there are 2 flags provided by the OS related to RA
handling. Rather than using the one that sets a preference between the Cell
vs. Wifi interface, at least Samsung (possibly others) have chosen to use
the other flag that says to completely ignore the WiFi RA if an RA on the
Cell interface has ever occurred. This means devices that have no IPv6 on
their Cell interface will appear to work fine on WiFi.


I just re-verified (same Nexus4 using 5.1.1 on swedish mobile provider 
Tele2):


I disable wifi.
I have dual stack on my mobile bearer (PDP context). Verified with 10/10 
for both ipv4 and ipv6 on test-ipv4.com (no 464xlat though, this is 
NAT44:ed IPv4 and native IPv6 on the mobile side).

I enable wifi.
After a few seconds the Nexus4 connects to my home wifi and starts using 
it, I get 10/10 for IPv4 on test-ipv4.com and 9/10 for IPv6 because my 
provider DNS resolver doesn't support native IPv6 lookups.


I claim that there is a platform bug, because there is never a reason to 
ignore the WiFi RA. Use the other flag to set a preference if that is 
needed, but ignoring the RA just breaks things in unexpected ways. LC 
has did a hand-wave that the "ignore RA" flag is needed for battery 
life, but beyond that we appear to be stuck in a world where Clueless 
OEMs believe in breaking one network when another might exist.


Well, it's not present on my Google device anyhow.

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Tue, 9 Jun 2015, Jon Bane wrote:

Seriously, this is how you are going to respond?  You are claiming you 
know what is best for everyone and I am telling you that I know is best 
for MY network. Who are you to even begin to understand my requirement 
or presume to know them better?


seriously?


You seem to fail to realise that you are not Lorenzos customer, his 
customer is the OEMs that build mobile phones, and their customers who buy 
Android phones.


So while you are doing what you think is best for your network, Lorenzo is 
doing what he thinks is best for his platform and the hundreds of millions 
of Android users that are out there.


So I happen to agree with Lorenzo that a single IA_NA per device world is 
a crippled world. Lorenzo said he was willing to work on a document that 
creates a recommendation for certain minimum amount of IPv6 addresses per 
device and/or PD, so let's get that happening then?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[Karl Auer]

On Wed, 2015-06-10 at 15:32 +0900, Lorenzo Colitti wrote:
> It's certainly possible to make Android request N IPv6 addresses via
> DHCPv6, and not accept the offer if it is offered fewer than N addresses.
> But that only really makes sense if there's a generally-agreed upon minimum
> value of N. 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.

You need as many as you need. Request them. Worry about it if you don't
get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is
almost certainly not going to have an upper limit that significantly
crimps your style...

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

RE: Android (lack of) support for DHCPv6

[Tony Hain]

From: Lorenzo Colitti [mailto:lore...@colitti.com] 
Sent: Tuesday, June 09, 2015 11:47 PM
To: Tony Hain
Cc: Mikael Abrahamsson; Chris Adams; NANOG
Subject: Re: Android (lack of) support for DHCPv6

On Wed, Jun 10, 2015 at 3:38 PM, Tony Hain  wrote:I claim 
that there is a platform bug, because there is never a reason to
ignore the WiFi RA. Use the other flag to set a preference if that is
needed, but ignoring the RA just breaks things in unexpected ways. LC has
did a hand-wave that the "ignore RA" flag is needed for battery life, but
beyond that we appear to be stuck in a world where Clueless OEMs believe in
breaking one network when another might exist.

This is not how current Android works. Each network can run IPv4, IPv6 or both 
independently of any other network. If you can reproduce this on a device 
running current Android (preferably a Nexus device), please file a bug.
 
There is indeed an issue with OEMs dropping RAs when the screen is off. Because 
it is the OEM that provides the wifi firmware and not Android, it's not really 
fair to say it's an Android bug. FWIW, recent Nexus devices do not have that 
bug.


My Nexus tablet does not have a Cell interface, and T-Mobile has stopped 
releasing updates for my phone, so I can't test that. For the issue I saw in 
the past, there was no screen-off event. All I had to do was enable the IPv6 
APN, and given that I live on the edge of the service area the link would drop 
at some point shortly after. At that point the expected behavior is that IPv6 
would still work via wifi, but no. While it still has an address, and can talk 
to anything on the wire, it has no router because that was removed and the RA 
is being ignored. 

I agree the OEM's are likely the problem here, but the platform should not 
allow them to create an invalid network state. Doing so only insures that they 
will pick the wrong options and break the network unnecessarily.

Tony

Re: Android (lack of) support for DHCPv6

[A . L . M . Buxey]

Hi,

> No, the premise is that from a user's point of view, DHCPv6-only networks

what about DHCPv6 for IPv6 and DHCP for IPv4 - the client should still be able 
to 
pick up an IPv6 addressinstead of forcing the only option to be SLAAC ?

alan

Re: Android (lack of) support for DHCPv6

[Matt Palmer]

On Tue, Jun 09, 2015 at 02:56:26PM -0700, Owen DeLong wrote:
> Further, the cellular companies would do well to be more adaptive to the
> capabilities that exist in the hardware rather than insisting that they
> choose the solution and the hardware makers must adapt.

Hahahahahaha!

Fun fill in the blanks game: "We're the phone company, __ ___'_  __ ."

- Matt

-- 
 The most secure computer in the world is one not connected to the
internet.  Thats why I recommend Telstra ADSL.
-- bash.org/?168859

Re: grepcidr 2.99

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In article <6dfdc9f9-ee28-4263-8e5b-eb751b35b...@dataix.net> you write:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Hi John,
>
>Great contribution. Thanks
>
>Might I make a suggestion? with the following command it gives Invalid CIDR. In
>my usage it would seem logically convenient to throw any quad octet at it and
>have it translate to the proper CIDR range that isn’t reported as invalid since
>it does this anyway. For instance 127.0.0.1/8 would just become 127.0.0.0/8.

Already does that with the -s for sloppy flag.

>Find it here:
>
>http://www.taugh.com/grepcidr-2/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlV38XsACgkQkEiFRdeC/kVMHQCfcy7D6fIrhIozpm2rwQ3C10g5
EOYAoKgARRkgkBy/+BRbMSKWd+fWWuaP
=9isH
-END PGP SIGNATURE-

Re: Android (lack of) support for DHCPv6

[Sander Steffann]

Hi Lorenzo,

> It's certainly possible to make Android request N IPv6 addresses via
> DHCPv6, and not accept the offer if it is offered fewer than N addresses.
> But that only really makes sense if there's a generally-agreed upon minimum
> value of N. 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.

I definitely think we should start pushing for N>1 because that will really 
hurt IPv6 in the future. However any fixed N is a potential danger as 
requirements will change in the future. But maybe we can do something smarter 
here.

> It's also possible for Android to support DHCPv6 PD. Again I'd be happy to
> work with people on a document that says that mobile devices should do
> DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar
> arguments will be had there.

I think this will be more difficult to get consensus on, and I can also see 
more deployment issues (much more state in the routers for all those PDs, 
needing huge amounts of /64s (or larger) to be able to deal with a few 
hundred/thousand clients) but it would be very nice if this was possible :)

> 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.

I don't think it is unreasonable. If the network doesn't support the features 
you need then let the user know (grey out the feature and add a note that says 
"broken network"). It will put pressure on the network department to fix their 
DHCPv6 implementation.

I have read Lorenzo's arguments and while I don't agree with all of them I do 
see the risk of creating a situation where N=1 is the default. That would be 
bad. But instead of not supporting DHCPv6 I think we should work on making sure 
N>>1.

Cheers,
Sander

Re: Android (lack of) support for DHCPv6

[A . L . M . Buxey]

Hi,

> 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.

talking of the user experience - any update on when Android will let the user
acknowledge a private CA and thus stop the 'your network may be monitored' alert
on each restart?  :/

alan

Re: Android (lack of) support for DHCPv6

[Baldur Norddahl]

We use DHCPv6 to assign just one IP address to the CPE. This is because
otherwise our routers do not know where to route the /48 that is also
passed along with DHCPv6-PD.

The routers are stupid I know, but it is what we got. So we simply
implemented a variant of static routes for 2001:db8:x::/48 to
2001:db8::x/128. The DHCP server knows to give you matching /48 and /128.

Apart from operational simplicity, we also do not want our routers to keep
track of a million ND cache entries. Our system pushes that down to the
CPE. In the network we only have one ND cache entry per customer.

The Android tethering guy seems to think that tethering should be a bridge.
But it should of course be routed. The phone in tethering mode should be
getting exactly what we do - one /128 on the uplink interface and a ton of
address space it can use internally and sub delegate to tethering clients.
What exactly is the argument against supporting a sane environment like
that?

As a side note, NAT is not the only solution if someone should try to block
tethering. I would propose a VPN tunnel. You can then have as much address
space you want from the VPN. This is extra easy if you are not locked into
the belief that tethering should be a bridge instead of routed.

Regards,

Baldur

Re: Android (lack of) support for DHCPv6

[Matt Palmer]

On Wed, Jun 10, 2015 at 10:31:25AM +0200, Sander Steffann wrote:
> I don't think it is unreasonable. If the network doesn't support the
> features you need then let the user know (grey out the feature and add a
> note that says "broken network").  It will put pressure on the network
> department to fix their DHCPv6 implementation.

Because that has worked so well in the past, as opposed to the helpdesk
person who receives the complaint shrugging their shoulders and saying, "I
dunno, that's just the way it is".

- Matt

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 4:13 PM, Karl Auer  wrote:

> You need as many as you need. Request them. Worry about it if you don't
> get them. This is exactly what happens when N=1, BTW. A DHCPv6 server is
> almost certainly not going to have an upper limit that significantly
> crimps your style...


Ok, let's see how that goes, even among the few people on this thread.

Question for everyone on this thread that has said that DHCPv6 NA is a
requirement: suppose that Android supported stateful DHCPv6 addressing,
requested a number of addresses, and did not use any of them if the number
of addresses received was less than N.

What does N need to be?

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann  wrote:

> I can also see more deployment issues (much more state in the routers for
> all those PDs, needing huge amounts of /64s (or larger) to be able to deal
> with a few hundred/thousand clients) but it would be very nice if this was
> possible :)
>

Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in
exactly the same way and give every client a /64. A /24 becomes a /56, and
your 10/8 becomes a /40. A /40 is really not hard to get.

Re: most accurate geo-IP source to build country-based access lists

[Dave Sparro]

Years ago when meeting with the lawyers to talk about the need to block
access to a list of websites I was coming from the technical side and
talking about how all of our possible solutions were incomplete and easily
circumvented by our users.  The lawyers' response was to explain the
concept of good faith effort.  The main point was that we needed to "do
something."  We'd be in pretty good shape liability-wise as long as we made
an attempt.   Getting back to the point of the question.  I'd find the
cheapest/easiest way to implement a somewhat effective GeoIP block, and say
that you've done something.

On Tue, Jun 9, 2015 at 11:13 AM, Joe Abley  wrote:

> On 9 Jun 2015, at 5:11, Martin T wrote:
>
>  At a brute force country level it is possible to use the Delegated
>>> ranges lists but that runs into the problem where IP ranges are
>>> subnetted and allocated to other countries.
>>>
>>
>> Yeah.
>>
>
> I would say that a perfectly accurate mapping of address to anything
> geographical (with more accuracy than "it's within the observed universe,
> somewhere") is unlikely ever to exist, except by accident and for short
> periods of time. Accuracy and lack of authoritative sources of data is one
> reason, constant uncoordinated reconfiguration is another. You need to
> decide how accurate your mapping needs to be (and figure out how to measure
> that, if accuracy is important).
>
> Another part of the problem is framing the question in a useful way: a
> universal solution seems intractable when the following questions are
> answered differently (but accurately) by different people who have
> different needs.
>
> Is a device in Uganda connected via satphone to a router in France in
> Uganda, or France?
>
> Is a network in Fiji that can't talk to any other networks in Fiji without
> leaving the island but is one layer-3 hop away from Australia in Fiji, or
> Australia?
>
> Does the source address of a packet always identify the device that sent
> the packet?
>
> If I'm in region A and you're in region A, and you route within region to
> me but my replies leave the region on the way back, are we in the same
> region from my perspective? How about yours?
>
> Even: if I'm in region A but I'm using a DNS resolver in region B, am I in
> region A or region B?
>
>
> Joe
>

Re: Android (lack of) support for DHCPv6

[Karl Auer]

On Wed, 2015-06-10 at 19:49 +0900, Lorenzo Colitti wrote:
> Question for everyone on this thread that has said that DHCPv6 NA is a
> requirement: suppose that Android supported stateful DHCPv6 addressing,
> requested a number of addresses, and did not use any of them if the number
> of addresses received was less than N.
> What does N need to be?

I think that's a wrong question, or maybe I am completely missing your
point.

Seems to me that N will vary depending on what you are trying to do. And
you could well be trying to do several things at once, each with a
different requirement. And these things may happen over time, so that at
one time you need N, while later you need ten times that many - or half
as many, or none. With DHCP you just ask for more when you need more, or
release ones you don't need. You don't have to arrange everything up
front and then be stuck with it.

You know how many addresses you need to provide a given service; you
know how to degrade the service gracefully, or whether a graceful
degrade is even possible. In other words, you the requester know how
many addresses you want and how many you have to have - which are two
possibly quite different numbers.

Addresses are just a resource, and like any other resource, if the
environment can't supply them, you either degrade the service, fail to
provide it, or possibly keep trying and provide it later when the
resource becomes available. At their most basic, standard DHCPv4 and
DHCPv6 clients do exactly that - they keep trying until they get
addresses.

Not being able to get enough addresses is pretty much like not being
able to get enough RAM or disk space, but you make it sound like running
out of power!

It is not an all-or-nothing proposition at a platform level, and
demanding to know "what is N?" implies that it is. 

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

So here is the thing.

You can try to use enhanced functionality which depends on multiple
addresses as justification for saying DHCPv6 is not supported.

In practice, your device will just not be supported.

As you pointed out, there isn't anything that forces adoption of IPv6 right
now.

If your client is broken because of an incomplete implementation, I just
won't give it an IPv6 address at all.  I think a lot of others feel the
same way.

At least on our network, the number of Apple devices dwarf Android by
several times.  With Android being a minority and not implementing DHCPv6
support you force us to make Android a second class citizen.

I'm perfectly find NATing Android, and don't see us giving up the
operational benefits to DHCPv6 anytime soon.

Also, in terms of hotspot functionality being the major driver ... I
already provide ubiquitous wireless coverage.  I don't want users enabling
a hotspot (rogue AP) on campus because it has a negative impact on service
for others, so the whole argument is really meaningless in the context of
higher education and campus networking.

A phone makes a terrible AP when the laptop supports full 802.11ac.  I
really don't know anyone who connects through their phone when WiFi is
available and the phone is also connected to the same WiFi network.  It's
not even a use case I think most people would consider common or valid but
we're using it a justification to not support something that IS very common
and widely deployed.





On Wed, Jun 10, 2015 at 7:16 AM, Lorenzo Colitti 
wrote:

> On Wed, Jun 10, 2015 at 5:31 PM, Sander Steffann 
> wrote:
>
> > I can also see more deployment issues (much more state in the routers for
> > all those PDs, needing huge amounts of /64s (or larger) to be able to
> deal
> > with a few hundred/thousand clients) but it would be very nice if this
> was
> > possible :)
> >
>
> Well, in IPv4 you can do 16M devices in 10/8. You can divide IPv6 space in
> exactly the same way and give every client a /64. A /24 becomes a /56, and
> your 10/8 becomes a /40. A /40 is really not hard to get.
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Android (lack of) support for DHCPv6

[A . L . M . Buxey]

Hi,

> Ok, let's see how that goes, even among the few people on this thread.
> 
> Question for everyone on this thread that has said that DHCPv6 NA is a
> requirement: suppose that Android supported stateful DHCPv6 addressing,
> requested a number of addresses, and did not use any of them if the number
> of addresses received was less than N.
> 
> What does N need to be?

well, from memory and a quick discussion with a colleague, our cisco wireless
kit is only happy with devices having 8 IPv6 addresses at most - otherwise
the older addresses get removed from the neighbour cache.

is that a good starting point?  :-)

alan

RE: Routing Insecurity (Re: BGP in the Washington Post)

[Russ White]

> > Crypto = more overhead.  Less priority to crypto plus DDoS = routing
> > update issues.
> 
> I don't think there's an update issue here. The crypto verification is 
> probably
> going to be deferred in addition to being low priority. If I understand it
> correctly, this means that a route can be passed along right away without
> waiting for the crypto checks.

I don't think this quite fits with Postel's law... There's also the size of the 
table and the ability to pack (compress) the information to consider. 

> > One can infer peering relationships in a way not possible before.
> 
> How?

The keys are per router, not per AS. You could use a single private/public key 
pair across the entire AS -- but that's not good security hygiene. There's no 
way to sign an update without exposing the signer; if you sign at anything 
below the AS level, you're exposing new information.

What about the per NLRI timer? The timer is essentially the amount of time 
you'd like someone to be able to advertise a route once the peering session is 
broken. How long are you comfortable with someone advertising your routes after 
you've taken down your peering with them? What's the performance impact of 
forcing every route in the table to expire, say, every 24 hours? Given your 
cost of setting your timers to a few minutes or hours is nil (you're 
transferring the cost of your increased security onto "everyone else"), why not 
set it lower? Tragedy of the commons? 

I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying it's 
is too heavyweight given the tradeoffs, and that we probably started with the 
wrong questions in the first place.

What's needed is to spend some time thinking about what questions really need 
to be answered, the lowest cost way to answer those questions, and a complete 
examination of the tradeoffs involved. Is "what path did this update travel," 
or "are the BGP semantics being properly followed," really questions that want 
asking? Or are there other, more pertinent questions available? 

:-)

Russ 

Lists of VPN exit addresses?

[John Levine]

Does anyone keep lists of the exit addresses of public VPN services?

I presume there is no need to explain why this would be of interest.

R's,
John

Re: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Wed, 10 Jun 2015, Baldur Norddahl wrote:


We use DHCPv6 to assign just one IP address to the CPE. This is because
otherwise our routers do not know where to route the /48 that is also
passed along with DHCPv6-PD.


If you use DHCPv6-PD you only need a LL address, you do not need a GUA 
address. Yes, a GUA WAN address is nice for fault finding, shows up in 
traceroute etc, but it's not needed. If your routers require a GUA WAN 
address in order for DHCPv6-PD to work, then they're not standards 
compliant.


Apart from operational simplicity, we also do not want our routers to 
keep track of a million ND cache entries. Our system pushes that down to 
the CPE. In the network we only have one ND cache entry per customer.


Well, if you have a GUA /128, then you have two per customer (because 
you'll have the LL one as well). If you didn't use the GUA address, you'd 
only have one.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer  wrote:

> Seems to me that N will vary depending on what you are trying to do.


Remember, what I'm trying to do is avoid user-visible regressions while
getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
buts, no requests to the network. The user turns it on, and it works.
IPv4-only apps always work.

A model where the device has to request resources from the network before
enabling tethering, or before supporting IPv4-only apps, provides a much
worse user experience. The user might have to wait a long time, or the
operation might even fail.

Re: Lists of VPN exit addresses?

[Roland Dobbins]

On 10 Jun 2015, at 18:56, John Levine wrote:


I presume there is no need to explain why this would be of interest.


To keep consumers who've legitimately purchased/rented/subscribed to 
content from accessing same when they travel internationally?


Because as a regular international traveler, that's what springs to mind 
when I see requests like this.


Another thought is governmentally-driven censorship, something else I 
encounter a lot in my travels.


---
Roland Dobbins 

Re: Routing Insecurity (Re: BGP in the Washington Post)

[Randy Bush]

> The keys are per router, not per AS.

rtfm.  bgpsec key aggregation is at the descretion of the operator.
they could use one key to cover 42 ASs.

randy

Re: Android (lack of) support for DHCPv6

[George Michaelson]

On Wed, Jun 10, 2015 at 2:06 PM, Lorenzo Colitti 
wrote:

> On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer  wrote:
>
> > Seems to me that N will vary depending on what you are trying to do.
>
>
> Remember, what I'm trying to do is avoid user-visible regressions while
> getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
> buts, no requests to the network. The user turns it on, and it works.
> IPv4-only apps always work.
>
> A model where the device has to request resources from the network before
> enabling tethering, or before supporting IPv4-only apps, provides a much
> worse user experience. The user might have to wait a long time, or the
> operation might even fail.
>

Laudible goal. I think with mifi devices typically limiting to 8/16 I have
a sense  that a /56 (which btw, was the unit we expected to use for
mass-customer deployment edge numbering) is going to be ok.

Its inevitable that in some other N+ years, we're going to be astonished by
how many IPs are needed behind the connecting device, but a /56->/64 gap is
going to work for now.

So pragmatism drives me to say 'we probably have enough in the model we're
working on'

I say this, because whilst I personally don't like the HD ratio model, its
what we adopted as a global measure of density of use, and I think
respecting allocation practice which reflects the HD ratio model is good,
and drives us to /56 for mass-customer deployments.

(I know there are policy people who may believe /48 is where we're going to
go. I can only say thats not how I understand address allocation modelling
works in many regions, right now. I also know there are people who think a
single customer can be a /128. I don't agree with that either)

-G

Re: Android (lack of) support for DHCPv6

[Jared Mauch]

> On Jun 10, 2015, at 8:06 AM, Lorenzo Colitti  wrote:
> 
> On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer  wrote:
> 
>> Seems to me that N will vary depending on what you are trying to do.
> 
> 
> Remember, what I'm trying to do is avoid user-visible regressions while
> getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
> buts, no requests to the network. The user turns it on, and it works.
> IPv4-only apps always work.
> 
> A model where the device has to request resources from the network before
> enabling tethering, or before supporting IPv4-only apps, provides a much
> worse user experience. The user might have to wait a long time, or the
> operation might even fail.

Sure, but when you take a NAT and replace it with no-NAT there will be no-NAT 
regressions as a result.

Perhaps doing 66 w/ ULA would provide a comparable experience?

IPv4 and IPv6 are enough alike that 99% of things “just work” but it’s in the 
1% of ARP v NDP, is what we’re talking about here.

- Jared

Re: Android (lack of) support for DHCPv6

[Karl Auer]

On Wed, 2015-06-10 at 21:06 +0900, Lorenzo Colitti wrote:
> On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer  wrote:
> > Seems to me that N will vary depending on what you are trying to do.
> A model where the device has to request resources from the network before
> enabling tethering, or before supporting IPv4-only apps, provides a much
> worse user experience. The user might have to wait a long time, or the
> operation might even fail.

I understand. I took issue only with the idea that any value of N could
be "right". Don't forget though that IPv4 phones also need resources
from the network - their public IPv4 addresses. Why isn't that a
showstopper too? Hm...

The essential difference with IPv6 compared to IPv4 is that (due to
address abundance) all addresses are (or at least can be) globally
routable. There can be a direct bidirectional relationship between a
connected device and the world; of necessity, that relationship brings
with it a higher degree of interdependence.

It's a pretty simple thing really: You can have all that that IPv6
offers (both now and potentially), or you can cripple it so that the
user experience is "just like IPv4".

I get where you are coming from. It's just a bit sad, is all.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

Re: Lists of VPN exit addresses?

[Jared Mauch]

> On Jun 10, 2015, at 8:08 AM, Roland Dobbins  wrote:
> 
> 
> On 10 Jun 2015, at 18:56, John Levine wrote:
> 
>> I presume there is no need to explain why this would be of interest.
> 
> To keep consumers who've legitimately purchased/rented/subscribed to content 
> from accessing same when they travel internationally?
> 
> Because as a regular international traveler, that's what springs to mind when 
> I see requests like this.
> 
> Another thought is governmentally-driven censorship, something else I 
> encounter a lot in my travels.

I’ll just simplify this and say that the Tor Project publishes a list of its 
exit nodes so you can block these if your abuse/fraud requirements necessitate 
this.

https://check.torproject.org/cgi-bin/TorBulkExitList.py

If it’s for geolocation blocking, I’m in favor of these political limitations 
to go away.  It doesn’t take a genius to bypass these if that’s your intent.

- Jared

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy  wrote:

> In practice, your device will just not be supported.
>
> As you pointed out, there isn't anything that forces adoption of IPv6
> right now.
>

It's certainly a possibility for both sides in this debate to say "my way
or the highway", and wait and see what happens when operators start
removing support for IPv4.


> I'm perfectly find NATing Android, and don't see us giving up the
> operational benefits to DHCPv6 anytime soon.
>

Oh, I definitely see that DHCPv6 is easier for network operators.

But even if you're dead set on using DHCPv6, what I don't see is why don't
you support DHCPv6 PD instead of IA_NA? It's the same amount of state. Same
accountability. Same transaction model. But unlike NA, the device gets as
many addresses as it needs. Nothing breaks, and you get future flexibility.
Mobile devices don't have to implement NAT, and application developers
don't have to work around it. You size your IPv6 pools based on the size of
your IPv4 pools, and don't run out of addresses. Technically, that sort of
arrangement is superior to IA_NA in basically every way. So... why use
IA_NA?

Even if the answers are "that's what we do in IPv4, and we want to do it
the same way", or "we're worried that this is strange and will tickle
vendor bugs", "it's not supported by the IPAM we use today", or "this is
what we've decided, our network our rules", I would hope that we as an
industry can think a little longer term than that.

Also, in terms of hotspot functionality being the major driver
>

Don't think about yesterday, think about tomorrow. Tethering and 464xlat
are just two examples of what can be done when you have the ability to use
more than one IPv6 address and cannot be done without that. We know these
will break today; tomorrow, we can use multiple addresses to do things we
haven't thought of yet.

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Lorenzo Colitti

> Remember, what I'm trying to do is avoid user-visible regressions
> while getting rid of NAT. Today in IPv4, tethering just works,
> period. No ifs, no buts, no requests to the network. The user turns
> it on, and it works.

*cough*

https://code.google.com/p/android/issues/detail?id=38563

In particular comment 105 is illuminating. Android is apparently fully
on-board with mobile carriers' desire to break tethering, even going so
far as to implement a feature whose *sole purpose* is to break
thethering.

Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it
*might*, as a *side effect*, break tethering. This does not strike me
as very consistent.

If Android had instead simply refused to establish a mobile data
connection to the mobile carriers that breaks tethering, then the
refusal to implement DHCPv6 would make much more sense.

Tore

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 9:31 PM, Tore Anderson  wrote:

> In particular comment 105 is illuminating. Android is apparently fully
> on-board with mobile carriers' desire to break tethering, even going so
> far as to implement a feature whose *sole purpose* is to break
> thethering.
>
> Yet, at the same time, you refuse to implement DHCPv6 on WiFi because it
> *might*, as a *side effect*, break tethering. This does not strike me
> as very consistent.
>

Tethering is just one example that we know about today. Another example is
464xlat. And that's not counting future applications that can take
advantage of multiple IP addresses that we haven't thought of yet, and that
we will have if we get stuck with
there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
networks.

Re: Android (lack of) support for DHCPv6

[Chris Adams]

Once upon a time, Lorenzo Colitti  said:
> Remember, what I'm trying to do is avoid user-visible regressions while
> getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
> buts, no requests to the network. The user turns it on, and it works.
> IPv4-only apps always work.

Except for the ones that don't.  Tethering is far from "just works,
period."  VPNs, VOIP, and games are things that don't always just work
(behind any kind of NAT).
-- 
Chris Adams 

Re: Android (lack of) support for DHCPv6

[Jared Mauch]

> On Jun 10, 2015, at 8:48 AM, Chris Adams  wrote:
> 
> Except for the ones that don't.  Tethering is far from "just works,
> period."  VPNs, VOIP, and games are things that don't always just work
> (behind any kind of NAT).


Please don’t bring facts into a discussion about ideologies of IPv6.


I think this is the problem that many of us face when dealing with the
day-to-date operational challenges of pitching IPv6 at others, many things
break for all sorts of reasons.  Those of us fighting to enable this
technology everywhere face a number of challenges from vendors
(8 IPv6 address limits, passive-aggressive bug-fixing, etc)

My favorite vendor bug fix for IPv6 up to this point was this one:

This is a point fix for a forwarding issue in ipv6 over bundle area. It does 
not enable/claim support of ipv6 over bundle

So you fix a bug but don’t claim support for the bug you just fixed.  Hmm.

Either way, we need to continue to push on these sensitive areas to make things 
happen.

I’m waiting for folks like Apple to turn on IPv6 on their CDN, or even deliver 
software updates over IPv6 to mobile devices.  I suspect that would be a 
watershed moment as most people see huge traffic jumps on iOS release day.  
(Next one is June 30th apparently).

Should be exciting.

- Jared

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6
let alone PD, so that's the discussion here, isn't it?

As for thinking "long term" and "the future", we need devices to work
within current models of IPv6 to accelerate _adoption_ of IPv6 _today_
before we can get to that future you're talking about.

Not supporting DHCPv6 ultimately holds back adoption, which makes people
see IPv6 as optional for longer, and discourages deployment because vendor
support is all over the place and seen as "not ready".

This isn't theory, we've been _living_ with this as a reality for years
now.  The networks are ready; the clients are not.

Universities see a constant stream of DMCA violation notices that need to
be dealt with and not being able to associate a specific IPv6 address to a
specific user is a big enough liability that the only option is to not use
IPv6.  As I said, Android becomes a second class citizen on the network
under your model.


On Wed, Jun 10, 2015 at 8:21 AM, Lorenzo Colitti 
wrote:

> On Wed, Jun 10, 2015 at 8:35 PM, Ray Soucy  wrote:
>
>> In practice, your device will just not be supported.
>>
>> As you pointed out, there isn't anything that forces adoption of IPv6
>> right now.
>>
>
> It's certainly a possibility for both sides in this debate to say "my way
> or the highway", and wait and see what happens when operators start
> removing support for IPv4.
>
>
>> I'm perfectly find NATing Android, and don't see us giving up the
>> operational benefits to DHCPv6 anytime soon.
>>
>
> Oh, I definitely see that DHCPv6 is easier for network operators.
>
> But even if you're dead set on using DHCPv6, what I don't see is why don't
> you support DHCPv6 PD instead of IA_NA? It's the same amount of state. Same
> accountability. Same transaction model. But unlike NA, the device gets as
> many addresses as it needs. Nothing breaks, and you get future flexibility.
> Mobile devices don't have to implement NAT, and application developers
> don't have to work around it. You size your IPv6 pools based on the size of
> your IPv4 pools, and don't run out of addresses. Technically, that sort of
> arrangement is superior to IA_NA in basically every way. So... why use
> IA_NA?
>
> Even if the answers are "that's what we do in IPv4, and we want to do it
> the same way", or "we're worried that this is strange and will tickle
> vendor bugs", "it's not supported by the IPAM we use today", or "this is
> what we've decided, our network our rules", I would hope that we as an
> industry can think a little longer term than that.
>
> Also, in terms of hotspot functionality being the major driver
>>
>
> Don't think about yesterday, think about tomorrow. Tethering and 464xlat
> are just two examples of what can be done when you have the ability to use
> more than one IPv6 address and cannot be done without that. We know these
> will break today; tomorrow, we can use multiple addresses to do things we
> haven't thought of yet.
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Android (lack of) support for DHCPv6

[Baldur Norddahl]

On 10 June 2015 at 14:03, Mikael Abrahamsson  wrote:

> On Wed, 10 Jun 2015, Baldur Norddahl wrote:
>
>  We use DHCPv6 to assign just one IP address to the CPE. This is because
>> otherwise our routers do not know where to route the /48 that is also
>> passed along with DHCPv6-PD.
>>
>
> If you use DHCPv6-PD you only need a LL address, you do not need a GUA
> address. Yes, a GUA WAN address is nice for fault finding, shows up in
> traceroute etc, but it's not needed. If your routers require a GUA WAN
> address in order for DHCPv6-PD to work, then they're not standards
> compliant.
>

I need the GUA to have a stable and predictable next hop for my static
route of the /48 prefix delegation.

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.

Note that the /48 static routes are configured on the routers well in
advantage of the customer even signing up for the service. It is just there
waiting for a customer to be assigned the corresponding /128.


>
>  Apart from operational simplicity, we also do not want our routers to
>> keep track of a million ND cache entries. Our system pushes that down to
>> the CPE. In the network we only have one ND cache entry per customer.
>>
>
> Well, if you have a GUA /128, then you have two per customer (because
> you'll have the LL one as well). If you didn't use the GUA address, you'd
> only have one.


Yes my bad, we will have exactly two cache entries per customer. That is
still better than SLAAC with unbounded caches and all the possibility of
getting DoS attacks on NDP, extra CPU use etc on my network. Why would I
want that, when I can deliver perfect service to the customer with a fixed
cache of 2 entries?

I have nothing against SLAAC it just does not belong in the carrier network.

Regards,

Baldur

Re: eBay is looking for network heavies...

[Jay Ashworth]

- Original Message -
> From: "Shane Ronan" 

> When I was asked the default BGP timers across three different vendor
> platforms as measure of my networking ability during an interview, I
> replied saying I'd look them up if needed them.
> 
> I was told I didn't understand BGP in enough detail, despite being able to
> describe all the steps of BGP session establishment and route
> exchange.
> 
> Certs have ruined the industry.

Maybe.  But they certainly saved you from having to work for an asshole
with misplaced priorities...

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

RE: Routing Insecurity (Re: BGP in the Washington Post)

[Russ White]

> rtfm.  bgpsec key aggregation is at the descretion of the operator.
> they could use one key to cover 42 ASs.

I've been reading the presentations and the mailing lists, both of which
imply you should use one key per router for security reasons. I would tend
to agree with that assessment, BTW. 

Russ 

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/9/15, 11:01 PM, "Lorenzo Colitti"  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 tha

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/9/15, 11:06 PM, "Lorenzo Colitti"  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: Routing Insecurity (Re: BGP in the Washington Post)

[Randy Bush]

>> rtfm.  bgpsec key aggregation is at the descretion of the operator.
>> they could use one key to cover 42 ASs.
> 
> I've been reading the presentations and the mailing lists, both of
> which imply you should use one key per router for security reasons.
> I would tend to agree with that assessment, BTW.

folk have different threat models.  yours (and mine) may be
propagation of router compromise.  for others, it might be a subtle
increase in disclosure of router links.  contrary to your original
assertion, the protocol supports both.

randy

RE: Routing Insecurity (Re: BGP in the Washington Post)

[Russ White]

> folk have different threat models.  yours (and mine) may be propagation of
> router compromise.  for others, it might be a subtle increase in
disclosure of
> router links.  contrary to your original assertion, the protocol supports
both.

The increased disclosure is not "subtle." The alternate -- deploying a new
key to every eBGP speaker in your network while the security of all your
routes is compromised, isn't so "subtle" either. It's a bad tradeoff in
either direction -- typical of solutions that ask the wrong questions in the
first place.

Russ

OT Fiber contractors?

[Jay Ashworth]

I have a client needs a couple outside under-parkinglot runs installed*, and
I'm so long out of that market I have no idea where to go.  Offlist recs 
for Tampa metro cheerfully accepted.  :-)

Cheers,
-- jra

[ * Pulled and terminated; we'll supply the switches and do the interconnect ]
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 2:32 AM, "Lorenzo Colitti"  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

[Mikael Abrahamsson]

On Wed, 10 Jun 2015, Baldur Norddahl wrote:


I need the GUA to have a stable and predictable next hop for my static
route of the /48 prefix delegation.

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.

Note that the /48 static routes are configured on the routers well in
advantage of the customer even signing up for the service. It is just there
waiting for a customer to be assigned the corresponding /128.


Well, then you're not doing what most people do when they do DHCPv6-PD, 
you're using something else. This is the first time I have heard of anyone 
doing what you describe.


Normally it's done by the router acting on DHCPv6 packets and installing a 
route if need be.


http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html

As soon as the PD is handed out, a corresponding route will be installed 
for that PD to the address (potentially LL address) that requested that 
PD.



getting DoS attacks on NDP, extra CPU use etc on my network. Why would I
want that, when I can deliver perfect service to the customer with a fixed
cache of 2 entries?


If you did PD the way it's normally done, you would need 1 entry, not 2.

I do agree that you do not want your equipment sitting in the same 
broadcast domain as all the customers devices, but do use PD. I'm just 
baffled by the way you have implemented "PD".


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

The whole conversation is around 464XLAT on IPv6-only networks right?
We're going to be dual-stack for a while IMHO, and by the time we can get
away with IPv6 only for WiFi, 464 should no longer be relevant because
we'll have widespread IPv6 adoption by then.

Carriers can do IPv6 only because they tightly control the clients, for
WiFi clients are and will always be all over the place, so dual stack will
be pretty much a given for a long time.


On Wed, Jun 10, 2015 at 9:50 AM, George, Wes 
wrote:

>
> On 6/10/15, 2:32 AM, "Lorenzo Colitti"  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.
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Android (lack of) support for DHCPv6

[George, Wes]

On 6/10/15, 9:13 AM, "Baldur Norddahl"  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: Access to nanog.cluepon.net

[Frank Bulk]

I see that nanog.cluepon.net is still down – is Richard S. *the* person for 
this?

 

Frank

 

From: Mike Hammett [mailto:na...@ics-il.net] 
Sent: Monday, June 08, 2015 1:47 PM
To: Josh Luthman
Cc: NANOG list; Frank Bulk
Subject: Re: Access to nanog.cluepon.net

 

Still down here (and apparently elsewhere as a request on another list was 
about it being down as well).



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

 

  _  

From: "Josh Luthman" mailto:j...@imaginenetworksllc.com> >
To: "Frank Bulk" mailto:frnk...@iname.com> >
Cc: "NANOG list" mailto:nanog@nanog.org> >
Sent: Saturday, June 6, 2015 12:33:17 PM
Subject: Re: Access to nanog.cluepon.net

Hasn't been working for about 20 minutes or more for me as well.


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Sat, Jun 6, 2015 at 1:27 PM, Frank Bulk mailto:frnk...@iname.com> > wrote:

> I'd like to update some material on nanog.cluepon.net (not very responsive
> to HTTP requests right now) and my account doesn't work anymore.  I reached
> out to Richard S. but have not heard back from him - anyone else here who
> has admin access and can set me up again?
>
> Frank
>
>

 

Re: Android (lack of) support for DHCPv6

[Mikael Abrahamsson]

On Wed, 10 Jun 2015, George, Wes wrote:



On 6/10/15, 9:13 AM, "Baldur Norddahl"  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.


http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-sy/dhcp-15-sy-book/ip6-dhcp-rel-agent.html#GUID-52D23F09-6829-4950-9431-92D9B7A255C0

"DHCPv6 Relay Agent Notification for Prefix Delegation

The DHCPv6 relay agent notification for prefix delegation allows the 
device working as a DHCPv6 relay agent to find prefix delegation options 
by reviewing the contents of a DHCPv6 RELAY-REPLY packet that is relayed 
by the relay agent to the client. When a prefix delegation option is found 
by the relay agent, the relay agent extracts the information about the 
prefix that is being delegated and inserts an IPv6 static route matching 
the prefix delegation information onto the relay agent. Future packets 
destined to that prefix via relay will be forwarded based on the 
information contained in the prefix delegation. The IPv6 static route is 
then left in the routing table until the prefix delegation lease time 
expires or the relay agent receives a release packet from the client 
releasing the prefix delegation."


I can't find IETF standards language apart from this:

"14.  Relay agent behavior

   A relay agent forwards messages containing Prefix Delegation options
   in the same way as described in section 20, "Relay Agent Behavior" of
   RFC 3315.

   If a delegating router communicates with a requesting router through
   a relay agent, the delegating router may need a protocol or other
   out-of-band communication to add routing information for delegated
   prefixes into the provider edge router."

From what I can find, a lot of vendors seem to have functionality 
implemented to look at the relayed messages and install static routes 
without any OOO-communication.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy  wrote:

> Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6
> let alone PD, so that's the discussion here, isn't it?
>

It is possible to implement DHCPv6 without implementing stateful address
assignment.

If there were consensus that delegating a prefix of sufficient size via
DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
IPv6 addressing in the environments that currently insist on stateful
DHCPv6 addressing, then it would make sense to implement it. In that
scenario, Android would still not implement DHCPv6 NA, but it would
implement DHCPv6 PD.

What needs to be gauged about that course of action is how much consensus
would be achieved, whether network operators would actually use it (IPv6
has a long and distinguished history of people claiming "I can't support
IPv6 until I get feature X", feature X appearing, and people changing their
claim to "I can't support IPv6 until I get feature Y"), and how much of
this discussion would be put to bed.

That course of action would seem most feasible if it were accompanied by an
IETF document that explained the deployment model and clarified what
"sufficient size" is.


> Universities see a constant stream of DMCA violation notices that need to
> be dealt with and not being able to associate a specific IPv6 address to a
> specific user is a big enough liability that the only option is to not use
> IPv6.
>

It's not the *only* option. There are large networks - O(100k) IPv6 nodes -
that do ND monitoring for accountability, and it does work for them. Many
devices support this via syslog, even. As you can imagine, my Android
device gets IPv6 at work, even though it doesn't support DHCPv6. Other
universities, too. It's obviously  not your chosen or preferred mechanism,
but it does work.

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

Respectfully disagree on all points.

The statement that "Android would still not implement DHCPv6 NA, but it
would implement DHCPv6 PD." is troubling because you're not even willing to
entertain the idea for reasons that are rooted in idealism rather
than pragmatism.

Very disappointing to see that this is the position of Google.


On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti 
wrote:

> On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy  wrote:
>
>> Actually we do support DHCPv6-PD, but Android doesn't even support DHCPv6
>> let alone PD, so that's the discussion here, isn't it?
>>
>
> It is possible to implement DHCPv6 without implementing stateful address
> assignment.
>
> If there were consensus that delegating a prefix of sufficient size via
> DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
> IPv6 addressing in the environments that currently insist on stateful
> DHCPv6 addressing, then it would make sense to implement it. In that
> scenario, Android would still not implement DHCPv6 NA, but it would
> implement DHCPv6 PD.
>
> What needs to be gauged about that course of action is how much consensus
> would be achieved, whether network operators would actually use it (IPv6
> has a long and distinguished history of people claiming "I can't support
> IPv6 until I get feature X", feature X appearing, and people changing their
> claim to "I can't support IPv6 until I get feature Y"), and how much of
> this discussion would be put to bed.
>
> That course of action would seem most feasible if it were accompanied by
> an IETF document that explained the deployment model and clarified what
> "sufficient size" is.
>
>
>> Universities see a constant stream of DMCA violation notices that need to
>> be dealt with and not being able to associate a specific IPv6 address to a
>> specific user is a big enough liability that the only option is to not use
>> IPv6.
>>
>
> It's not the *only* option. There are large networks - O(100k) IPv6 nodes
> - that do ND monitoring for accountability, and it does work for them. Many
> devices support this via syslog, even. As you can imagine, my Android
> device gets IPv6 at work, even though it doesn't support DHCPv6. Other
> universities, too. It's obviously  not your chosen or preferred mechanism,
> but it does work.
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Wed, Jun 10, 2015 at 10:25 PM, George, Wes 
wrote:

> 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.
>

Thank you for trying to reword what I tried to express. Your assessment
pretty much matches mine, except for the conclusion (see below).


> 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.
>

Yep (but perhaps in v6ops instead of sunset4, see below).


> 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
> yourself admit basically don't exist today by blocking support for
> something that we could use today to have more devices using IPv6, were it
> available.
>

I disagree with this part of the conclusion. 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.

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

Ray,

please do not construe my words on this thread as being Google's position
on anything. These messages were sent from my personal email address, and I
do not speak for my employer.

Regards,
Lorenzo

On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy  wrote:

> Respectfully disagree on all points.
>
> The statement that "Android would still not implement DHCPv6 NA, but it
> would implement DHCPv6 PD." is troubling because you're not even willing to
> entertain the idea for reasons that are rooted in idealism rather
> than pragmatism.
>
> Very disappointing to see that this is the position of Google.
>
>
> On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti 
> wrote:
>
>> On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy  wrote:
>>
>>> Actually we do support DHCPv6-PD, but Android doesn't even support
>>> DHCPv6 let alone PD, so that's the discussion here, isn't it?
>>>
>>
>> It is possible to implement DHCPv6 without implementing stateful address
>> assignment.
>>
>> If there were consensus that delegating a prefix of sufficient size via
>> DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
>> IPv6 addressing in the environments that currently insist on stateful
>> DHCPv6 addressing, then it would make sense to implement it. In that
>> scenario, Android would still not implement DHCPv6 NA, but it would
>> implement DHCPv6 PD.
>>
>> What needs to be gauged about that course of action is how much consensus
>> would be achieved, whether network operators would actually use it (IPv6
>> has a long and distinguished history of people claiming "I can't support
>> IPv6 until I get feature X", feature X appearing, and people changing their
>> claim to "I can't support IPv6 until I get feature Y"), and how much of
>> this discussion would be put to bed.
>>
>> That course of action would seem most feasible if it were accompanied by
>> an IETF document that explained the deployment model and clarified what
>> "sufficient size" is.
>>
>>
>>> Universities see a constant stream of DMCA violation notices that need
>>> to be dealt with and not being able to associate a specific IPv6 address to
>>> a specific user is a big enough liability that the only option is to not
>>> use IPv6.
>>>
>>
>> It's not the *only* option. There are large networks - O(100k) IPv6 nodes
>> - that do ND monitoring for accountability, and it does work for them. Many
>> devices support this via syslog, even. As you can imagine, my Android
>> device gets IPv6 at work, even though it doesn't support DHCPv6. Other
>> universities, too. It's obviously  not your chosen or preferred mechanism,
>> but it does work.
>>
>
>
>
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
>
> T: 207-561-3526
> F: 207-561-3531
>
> MaineREN, Maine's Research and Education Network
> www.maineren.net
>

Re: Android (lack of) support for DHCPv6

[Masataka Ohta]

Lorenzo Colitti wrote:

> It's not the *only* option. There are large networks - O(100k) IPv6 nodes -
> that do ND monitoring for accountability, and it does work for them. Many
> devices support this via syslog, even. As you can imagine, my Android
> device gets IPv6 at work, even though it doesn't support DHCPv6. Other
> universities, too. It's obviously  not your chosen or preferred mechanism,
> but it does work.

Considering that a DOS attack from a node using a lot of addresses to
effectively disable logging, SLAAC must not be used, unless maximum N,
the maximum number of addresses for a node to have, is standardized (
assuming a node is securely identified through the first hop security,
which is necessary to enforce the number of addresses used by each node).

Masataka Ohta

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Lorenzo Colitti

> Tethering is just one example that we know about today. Another example is
> 464xlat.

You can't do 464XLAT without the network operator's help anyway (unless
you/Google is planning on hosting a public NAT64 service?). If the
network operator actively wants 464XLAT to be used, by providing
DNS64/NAT64 service, then it seems fairly reasonable to assume that
they're not going to deploy an IPv6/DHCPv6-only network that limits the
number of IA_NA per attached node to 1.

> And that's not counting future applications that can take
> advantage of multiple IP addresses that we haven't thought of yet, and that
> we will have if we get stuck with
> there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
> networks.

Of course. Hard to argue against imaginary things. :-)

On the other hand, there exist applications *today* that do require
DHCPv6. One such example would be MAP, which IMHO is superior to
464XLAT both for the network operator (statlessness ftw) as well as for
the end user (unsolicited inbound packets work, no NAT traversal
required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
so without DHCPv6 support in Android, MAP support in Android is a
non-starter.

Tore

Re: Android (lack of) support for DHCPv6

[Baldur Norddahl]

On 10 June 2015 at 15:53, Mikael Abrahamsson  wrote:

>
> Well, then you're not doing what most people do when they do DHCPv6-PD,
> you're using something else. This is the first time I have heard of anyone
> doing what you describe.
>

I mentioned because the Android guy seems to be guilty of knowing how
everyone does or want to run their network. There are always more ways to
do this than you thought of.

Normally it's done by the router acting on DHCPv6 packets and installing a
> route if need be.
>

I would probably do it like that if my equipment had support. But it does
not. And I can not point at any RFCs to tell my vendor that their stuff is
broken, because the requirement simply is not in any RFCs.

Also consider this:

1) The DHCP relay might not be the same router that needs to do the
forwarding.
2) There might be more than one router that can forward.
3) There might not even be a DHCP relay, the DHCP server could be attached
directly.

In our case we have GPON access switches that do DHCP(v6) snooping. These
things can block illegal traffic, but other than that, they are purely
layer 2 devices. There is no relay there and no layer 3 forwarding, so no
routes can be installed by anything.

Upstream from the access switches there are many ways you can structure
your network. You might want to have two routers for redundancy. You may
attach the DHCP server directly here if it is a small network (although we
use relays).

Static routes with a fixed GUA next hop for the /48 prefix delegations
means you can have some pretty dumb (=cheap) stuff in your network. All you
need is an intelligent DHCP server and that is just open source software on
a Linux.

I considered having the DHCP server add the routes via a script that is
triggered by lease handout. But the fixed static routes is much simpler and
robust.


> I do agree that you do not want your equipment sitting in the same
> broadcast domain as all the customers devices, but do use PD. I'm just
> baffled by the way you have implemented "PD".
>
>
We all work with the equipment we got and the quirks in there. Just do not
go around and assume everyone has the same requirements as you. Saying
there is no use case for DHCPv6 except for PD is dumb and that was why I
put forward a use case to illustrate how this is used in the real world. At
least by us.

Regards,

Baldur

Re: Routing Insecurity (Re: BGP in the Washington Post)

[Sandra Murphy]

On Jun 10, 2015, at 7:51 AM, "Russ White"  wrote:

> 
> I'm not saying BGPSEC a bad solution for the questions asked -- I'm saying 
> it's is too heavyweight given the tradeoffs, and that we probably started 
> with the wrong questions in the first place.
> 
> What's needed is to spend some time thinking about what questions really need 
> to be answered, the lowest cost way to answer those questions, and a complete 
> examination of the tradeoffs involved. Is "what path did this update travel," 
> or "are the BGP semantics being properly followed," really questions that 
> want asking? Or are there other, more pertinent questions available? 
> 

Not liking the solution is not a reason to abandon the problem.  This sounds 
like "I don't like eating right and exercising, so keeping my weight under 
control is the wrong question"

All protocols rely on certain assumptions of what the fields mean - when you 
send them and when you receive them.  Analyzing a protocol for vulnerabilities 
starts with identifying what happens if those assumptions are broken.  (Like 
the assumption in IP that the source address is the node that sent the packet - 
spoofing breaks that assumption.)  Breaking the semantics creates attacks.

--Sandy



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Routing Insecurity (Re: BGP in the Washington Post)

[Sandra Murphy]

There have been suggestions that a key-per-AS is easier to manage than a 
key-per-router, like in provisioning.

Key-per-router was brought up as providing the means to excise one misbehaving 
router that is in some risky sort of environment, which is a different 
management pain.

In terms of security, from outside the AS, you are basing your decisions on 
your trust in the AS in the key-per-AS case, and you are basing your decisions 
on your trust in the AS that certified the router in the key-per-router case.

The local operator's environment and policy rule in choosing the technique.

The draft draft-ietf-sidr-bgpsec-ops-05 says:

   A site/operator MAY use a single certificate/key in all their
   routers, one certificate/key per router, or any granularity in
   between.

--Sandy

On Jun 10, 2015, at 9:17 AM, "Russ White"  wrote:

> 
>> rtfm.  bgpsec key aggregation is at the descretion of the operator.
>> they could use one key to cover 42 ASs.
> 
> I've been reading the presentations and the mailing lists, both of which
> imply you should use one key per router for security reasons. I would tend
> to agree with that assessment, BTW. 
> 
> Russ 



signature.asc
Description: Message signed with OpenPGP using GPGMail

RE: Android (lack of) support for DHCPv6

[Tony Hain]

Ray Soucy  wrote:
> 
> Respectfully disagree on all points.
> 
> The statement that "Android would still not implement DHCPv6 NA, but it would
> implement DHCPv6 PD." is troubling because you're not even willing to
> entertain the idea for reasons that are rooted in idealism rather than
> pragmatism.

In Lorenzo's defense, I believe he is taking the long term pragmatic position, 
while you appear to be taking the short term idealistic position. 

For argument's sake... let's assume that a shiny new browser comes along the is 
designed to limit third party cross site correlation and tracking. It does this 
by using a different source address for every destination. This browser works 
fine on any network that allows N>1, but is stuck in the myopic historical 
world of older browsers on networks where N=1. To the pragmatism point, would 
you rather have a device like that do N NA requests (creating N ND state 
entries), or have it do PD (creating 1 ND + 1 Routing entry)?

Tony

> 
> Very disappointing to see that this is the position of Google.
> 
> 
> On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti 
> wrote:
> 
> > On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy  wrote:
> >
> >> Actually we do support DHCPv6-PD, but Android doesn't even support
> >> DHCPv6 let alone PD, so that's the discussion here, isn't it?
> >>
> >
> > It is possible to implement DHCPv6 without implementing stateful
> > address assignment.
> >
> > If there were consensus that delegating a prefix of sufficient size
> > via
> > DHCPv6 PD of a sufficient size is an acceptable substitute for
> > stateful
> > IPv6 addressing in the environments that currently insist on stateful
> > DHCPv6 addressing, then it would make sense to implement it. In that
> > scenario, Android would still not implement DHCPv6 NA, but it would
> > implement DHCPv6 PD.
> >
> > What needs to be gauged about that course of action is how much
> > consensus would be achieved, whether network operators would actually
> > use it (IPv6 has a long and distinguished history of people claiming
> > "I can't support
> > IPv6 until I get feature X", feature X appearing, and people changing
> > their claim to "I can't support IPv6 until I get feature Y"), and how
> > much of this discussion would be put to bed.
> >
> > That course of action would seem most feasible if it were accompanied
> > by an IETF document that explained the deployment model and clarified
> > what "sufficient size" is.
> >
> >
> >> Universities see a constant stream of DMCA violation notices that
> >> need to be dealt with and not being able to associate a specific IPv6
> >> address to a specific user is a big enough liability that the only
> >> option is to not use IPv6.
> >>
> >
> > It's not the *only* option. There are large networks - O(100k) IPv6
> > nodes
> > - that do ND monitoring for accountability, and it does work for them.
> > Many devices support this via syslog, even. As you can imagine, my
> > Android device gets IPv6 at work, even though it doesn't support
> > DHCPv6. Other universities, too. It's obviously  not your chosen or
> > preferred mechanism, but it does work.
> >
> 
> 
> 
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network www.maineren.net

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Thu, Jun 11, 2015 at 12:35 AM, Tore Anderson  wrote:

> > And that's not counting future applications that can take
> > advantage of multiple IP addresses that we haven't thought of yet, and
> that
> > we will have if we get stuck with
> >
> there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
> > networks.
>
> Of course. Hard to argue against imaginary things. :-)
>

I think "imaginary" is the wrong word here. There's a difference between
imaginary things and leaving room for for future innovation. Phone network
model vs. Internet model is the usual example that comes to mind.


> On the other hand, there exist applications *today* that do require
> DHCPv6. One such example would be MAP, which IMHO is superior to
> 464XLAT both for the network operator (statlessness ftw) as well as for
> the end user (unsolicited inbound packets work, no NAT traversal
> required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
> so without DHCPv6 support in Android, MAP support in Android is a
> non-starter.
>

Support for the DHCPv6 protocol, or support for assigning addresses from
IA_NA?

Re: Android (lack of) support for DHCPv6

[Jeff McAdams]

Then you need to be far more careful about what you say. When you said "Android 
would still not support..." you, very clearly, made a statement of product 
direction for a Google product. There is no other rational way to interpret 
your statement than to be a statement of Google's position.

-- 
Jeff

On Jun 10, 2015 10:26 AM, Lorenzo Colitti  wrote:
>
> Ray, 
>
> please do not construe my words on this thread as being Google's position 
> on anything. These messages were sent from my personal email address, and I 
> do not speak for my employer. 
>
> Regards, 
> Lorenzo 
>
> On Thu, Jun 11, 2015 at 12:15 AM, Ray Soucy  wrote: 
>
> > Respectfully disagree on all points. 
> > 
> > The statement that "Android would still not implement DHCPv6 NA, but it 
> > would implement DHCPv6 PD." is troubling because you're not even willing to 
> > entertain the idea for reasons that are rooted in idealism rather 
> > than pragmatism. 
> > 
> > Very disappointing to see that this is the position of Google. 
> > 
> > 
> > On Wed, Jun 10, 2015 at 10:58 AM, Lorenzo Colitti  
> > wrote: 
> > 
> >> On Wed, Jun 10, 2015 at 10:06 PM, Ray Soucy  wrote: 
> >> 
> >>> Actually we do support DHCPv6-PD, but Android doesn't even support 
> >>> DHCPv6 let alone PD, so that's the discussion here, isn't it? 
> >>> 
> >> 
> >> It is possible to implement DHCPv6 without implementing stateful address 
> >> assignment. 
> >> 
> >> If there were consensus that delegating a prefix of sufficient size via 
> >> DHCPv6 PD of a sufficient size is an acceptable substitute for stateful 
> >> IPv6 addressing in the environments that currently insist on stateful 
> >> DHCPv6 addressing, then it would make sense to implement it. In that 
> >> scenario, Android would still not implement DHCPv6 NA, but it would 
> >> implement DHCPv6 PD. 
> >> 
> >> What needs to be gauged about that course of action is how much consensus 
> >> would be achieved, whether network operators would actually use it (IPv6 
> >> has a long and distinguished history of people claiming "I can't support 
> >> IPv6 until I get feature X", feature X appearing, and people changing 
> >> their 
> >> claim to "I can't support IPv6 until I get feature Y"), and how much of 
> >> this discussion would be put to bed. 
> >> 
> >> That course of action would seem most feasible if it were accompanied by 
> >> an IETF document that explained the deployment model and clarified what 
> >> "sufficient size" is. 
> >> 
> >> 
> >>> Universities see a constant stream of DMCA violation notices that need 
> >>> to be dealt with and not being able to associate a specific IPv6 address 
> >>> to 
> >>> a specific user is a big enough liability that the only option is to not 
> >>> use IPv6. 
> >>> 
> >> 
> >> It's not the *only* option. There are large networks - O(100k) IPv6 nodes 
> >> - that do ND monitoring for accountability, and it does work for them. 
> >> Many 
> >> devices support this via syslog, even. As you can imagine, my Android 
> >> device gets IPv6 at work, even though it doesn't support DHCPv6. Other 
> >> universities, too. It's obviously  not your chosen or preferred mechanism, 
> >> but it does work. 
> >> 
> > 
> > 
> > 
> > -- 
> > Ray Patrick Soucy 
> > Network Engineer 
> > University of Maine System 
> > 
> > T: 207-561-3526 
> > F: 207-561-3531 
> > 
> > MaineREN, Maine's Research and Education Network 
> > www.maineren.net 
> > 

Re: Android (lack of) support for DHCPv6

[Lorenzo Colitti]

On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams  wrote:

> Then you need to be far more careful about what you say. When you said
> "Android would still not support..." you, very clearly, made a statement of
> product direction for a Google product.


Did you intentionally leave the "in that scenario," words that came right
before the ones you quoted?

How does a sentence that says "in that scenario, android would "
constitute a statement of direction?

Re: Lists of VPN exit addresses?

[Bacon Zombie]

Well if they are using Hola then EVERY person with it installed is an
exit-node.

http://adios-hola.org

https://m.reddit.com/r/netsec/comments/37rit3/adios_hola_why_you_should_immediately_uninstall/
On 10 Jun 2015 14:28, "Jared Mauch"  wrote:

>
> > On Jun 10, 2015, at 8:08 AM, Roland Dobbins  wrote:
> >
> >
> > On 10 Jun 2015, at 18:56, John Levine wrote:
> >
> >> I presume there is no need to explain why this would be of interest.
> >
> > To keep consumers who've legitimately purchased/rented/subscribed to
> content from accessing same when they travel internationally?
> >
> > Because as a regular international traveler, that's what springs to mind
> when I see requests like this.
> >
> > Another thought is governmentally-driven censorship, something else I
> encounter a lot in my travels.
>
> I’ll just simplify this and say that the Tor Project publishes a list of
> its exit nodes so you can block these if your abuse/fraud requirements
> necessitate this.
>
> https://check.torproject.org/cgi-bin/TorBulkExitList.py
>
> If it’s for geolocation blocking, I’m in favor of these political
> limitations to go away.  It doesn’t take a genius to bypass these if that’s
> your intent.
>
> - Jared

Re: Android (lack of) support for DHCPv6

[Dave Taht]

On Wed, Jun 10, 2015 at 8:35 AM, Tore Anderson  wrote:
> * Lorenzo Colitti
>
>> Tethering is just one example that we know about today.

In android's case I am perpetually bemused by the fact they use
dnsmasq for tethered dhcp, and dnsmasq long ago added support for
doing smarter things with slaac, and dhcpv6. Merely upgrading that
package in the android distro would get everything needed except
dhcp-pd support into android (for which openwrt has got some decent
daemons for).

dnsmasq is not used in android for dns (which is too bad as dnssec
support was also added to it and I hope most of the bugs ironed out,
in the last 3 years), as their dns resolver is in java and is
admittedly mildly more secure if less featureful.

I am told that well over 50% of all android development comes from
volunteer developers so rather than kvetching about this it seems
plausible for an outside effort to get the needed features for
tethering and using dhcpv6-pd into it. If someone wanted to do the
work.

>> Another example is
>> 464xlat.
>
> You can't do 464XLAT without the network operator's help anyway (unless
> you/Google is planning on hosting a public NAT64 service?). If the
> network operator actively wants 464XLAT to be used, by providing
> DNS64/NAT64 service, then it seems fairly reasonable to assume that
> they're not going to deploy an IPv6/DHCPv6-only network that limits the
> number of IA_NA per attached node to 1.
>
>> And that's not counting future applications that can take
>> advantage of multiple IP addresses that we haven't thought of yet, and that
>> we will have if we get stuck with
>> there-are-more-IPv6-addresses-in-this-subnet-than-grains-of-sand-but-you-only-get-one-because-that's-how-we-did-it-in-IPv4
>> networks.
>
> Of course. Hard to argue against imaginary things. :-)
>
> On the other hand, there exist applications *today* that do require
> DHCPv6. One such example would be MAP, which IMHO is superior to
> 464XLAT both for the network operator (statlessness ftw) as well as for
> the end user (unsolicited inbound packets work, no NAT traversal
> required). MAP is provisioned with DHCPv6 (I-D.ietf-softwire-map-dhcp),
> so without DHCPv6 support in Android, MAP support in Android is a
> non-starter.
>
> Tore



-- 
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: Android (lack of) support for DHCPv6

[Scott Whyte]

On 6/10/15 08:36, Jeff McAdams wrote:

There is no
other rational way to interpret your statement than to be a statement
of Google's position.



False dichotomies suck.

Re: Android (lack of) support for DHCPv6

[Jared Mauch]

> On Jun 10, 2015, at 11:36 AM, Jeff McAdams  wrote:
> 
> There is no other rational way to interpret your statement than to be a 
> statement of Google's position.

As someone who posts from a personal email but my management has told me that 
I’m well identifiable as who I work for, I’m sympathetic to the way one can 
suffer a bit of personality split when certain business realities come into 
play.  I’m sure people might mock me for it, but lots of people have mocked me 
for years so why should I care about this one so much?

When a business reality or necessity hits you in the face, sometimes you can’t 
do anything about it.

Would I have preferred if Apple and AT&T let me tether on my grandfathered 
unlimited plan?  Sure.  Could I do this before on my unlimited GPRS/Edge plan 
with my Nokia?  Of course, but the reality is I can just carry another 
device/SIM and use a tablet to tether.

As google is in a business of selling ads on the internet, I can see why they 
might not want to pick a fight with a carrier at every stage in the process.  
The ROI just isn’t there is my guess.

IPv6 is mature enough to be widely deployed, but some of these cases need to 
have some give/take on both sides to work out.  I’m reminded of the adage of if 
both sides are unhappy you cut the baby properly in half.

- jared

Re: Android (lack of) support for DHCPv6

[Jeff McAdams]

Re: Android (lack of) support for DHCPv6

[Karl Auer]

On Wed, 2015-06-10 at 09:49 -0700, Scott Whyte wrote:
> False dichotomies suck.

There are only two kinds of dichotomy... those that suck and those that
do not. This one sucks.

Regards, K.


-- 
~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://twitter.com/kauer389

GPG fingerprint: 3C41 82BE A9E7 99A1 B931 5AE7 7638 0147 2C3C 2AC4
Old fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882

Re: Android (lack of) support for DHCPv6

[Ray Soucy]

I don't really feel I was trying to take things out of context, but the
full quote would be:

"If there were consensus that delegating a prefix of sufficient size via
DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
IPv6 addressing in the environments that currently insist on stateful
DHCPv6 addressing, then it would make sense to implement it. In that
scenario, Android would still not implement DHCPv6 NA, but it would
implement DHCPv6 PD."

To me, that's essentially saying:

"EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will
never support stateful address assignment via DHCPv6."

This rings especially true when compared against the context of everything
else you've written on the subject.

I think that's how most others on this list would read it as well.

If that isn't what you meant to say, then I'm sorry.  I'm certainly not
trying to put words in your mouth.

I still feel that it's a very poor position to take.

Given that you don't speak for Google on the subject, if you're not
the decision maker for this issue on Android, could you pull in the people
at Google who are, or at least point us to them?

A lot of us would like the chance to make our case and expose the harm that
Android is doing by not supporting DHCPv6.

I think the Android team is very overconfident in their ability to shape
the direction of IPv6 adoption, especially with years old Android releases
being still in production and it taking incredibly long for changes to
trickle down through the Android ecosystem.

That delay is also why we have a hard time accepting the mindset that IF
you see a need for it in the future you'll add it.  That will be 4 to 8
years too late.





On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti 
wrote:

> On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams  wrote:
>
>> Then you need to be far more careful about what you say. When you said
>> "Android would still not support..." you, very clearly, made a statement of
>> product direction for a Google product.
>
>
> Did you intentionally leave the "in that scenario," words that came right
> before the ones you quoted?
>
> How does a sentence that says "in that scenario, android would "
> constitute a statement of direction?
>



-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: Android (lack of) support for DHCPv6

[Sander Steffann]

> 
> It's not the *only* option. There are large networks - O(100k) IPv6 nodes - 
> that do ND monitoring for accountability, and it does work for them. Many 
> devices support this via syslog, even. As you can imagine, my Android device 
> gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, 
> too. It's obviously  not your chosen or preferred mechanism, but it does work.

/me starts to write that whitepaper that educates people on how to do this

Cheers,
Sander

Re: Android (lack of) support for DHCPv6

[George, Wes]

From: Lorenzo Colitti mailto:lore...@colitti.com>>
Date: Wednesday, June 10, 2015 at 11:21 AM
To: "George, Wes" mailto:wesley.geo...@twcable.com>>
Cc: NANOG mailto: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

[Ray Soucy]

I've already written systems to do this kind of thing, but the logging
requirements quickly go through the roof for a non-trivial network;
especially in the case of temporary addressing now default on many
systems.  That isn't so much the issue as operational consistency and
supportability.

The requirement for hosts to be dual stack will exist for some time.

For the sanity of IT workers and users alike (most of which don't really
know the details of IPv6 and barely understand address scopes let alone
multiple addresses) there needs to be some level of consistency between how
hosts are addressed and communicate between the two protocols.  Saying
we'll develop one system for IPv4 and one for IPv6 ultimate results in
"Let's not deploy IPv6 just yet".

This rings especially true when security concerns come up.  Consistency
between IPv4 and IPv6 needs to be possible in this transition period, or
people simply decide to not deploy.  Consistency in addressing and
maintaining a one host one address model has major implications for policy
construction, flow analysis and incident response, denial of service
mitigation, etc.  If the consistency isn't there, you need to "re-invent
the wheel" for every aspect, then maintain different systems for IPv4 and
IPv6 along side one another.

Even worse, if we keep seeing adoption held up by inconsistent client
implementations I fear we'll start seeing commercial products which NAT or
proxy IPv4 to IPv6 to avoid using IPv6 internally.  It's very ugly and
requires some DNS magic to work, but it's not impossible.  We're already
seeing this in terms of cloud computing and virtualization.  Servers have
IPv4 addresses and only a load balancer with an external IPv6 address.

We absolutely need to make it possible for people to adopt IPv6 before we
can reach a point where IPv4 can go away, and for some organizations the
answer of "Just use SLAAC" is simply not acceptable.

They just won't do it.

Preventing IPv6 adoption hurts us all.  And Android not supporting a MAJOR
part of IPv6 like DHCPv6 is preventing adoption.





On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann  wrote:

> >
> > It's not the *only* option. There are large networks - O(100k) IPv6
> nodes - that do ND monitoring for accountability, and it does work for
> them. Many devices support this via syslog, even. As you can imagine, my
> Android device gets IPv6 at work, even though it doesn't support DHCPv6.
> Other universities, too. It's obviously  not your chosen or preferred
> mechanism, but it does work.
>
> /me starts to write that whitepaper that educates people on how to do this
>
> Cheers,
> Sander
>
>


-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net

Re: eBay is looking for network heavies...

[goemon]

On Tue, 9 Jun 2015, Jay Ashworth wrote:

- Original Message -

From: "Shane Ronan" 
When I was asked the default BGP timers across three different vendor
platforms as measure of my networking ability during an interview, I
replied saying I'd look them up if needed them.

I was told I didn't understand BGP in enough detail, despite being able to
describe all the steps of BGP session establishment and route
exchange.
Certs have ruined the industry.

Maybe.  But they certainly saved you from having to work for an asshole
with misplaced priorities...


Indeed, the interview process is a two way street. Lets you evaluate who 
you would be working for -- or if you really would want to.


-Dan

RE: Android (lack of) support for DHCPv6

[Tony Hain]

Ray Soucy wrote:
> I don't really feel I was trying to take things out of context, but the full 
> quote
> would be:
> 
> "If there were consensus that delegating a prefix of sufficient size via
> DHCPv6 PD of a sufficient size is an acceptable substitute for stateful
> IPv6 addressing in the environments that currently insist on stateful
> DHCPv6 addressing, then it would make sense to implement it. In that scenario,
> Android would still not implement DHCPv6 NA, but it would implement DHCPv6
> PD."
> 
> To me, that's essentially saying:
> 
> "EVEN IF we decided to support DHCPv6-PD, and that's a big IF, we will never
> support stateful address assignment via DHCPv6."
> 
> This rings especially true when compared against the context of everything 
> else
> you've written on the subject.
> 
> I think that's how most others on this list would read it as well.
> 
> If that isn't what you meant to say, then I'm sorry.  I'm certainly not 
> trying to put
> words in your mouth.
> 
> I still feel that it's a very poor position to take.
> 
> Given that you don't speak for Google on the subject, if you're not the 
> decision
> maker for this issue on Android, could you pull in the people at Google who 
> are,
> or at least point us to them?
> 
> A lot of us would like the chance to make our case and expose the harm that
> Android is doing by not supporting DHCPv6.
> 
> I think the Android team is very overconfident in their ability to shape the
> direction of IPv6 adoption, especially with years old Android releases being 
> still
> in production and it taking incredibly long for changes to trickle down 
> through
> the Android ecosystem.
> 
> That delay is also why we have a hard time accepting the mindset that IF you
> see a need for it in the future you'll add it.  That will be 4 to 8 years too 
> late.
> 
> 
> 

So the flip side of that point is; how many decades does it take to trickle 
things through the operational networks? Having seen this first hand at the 
operator, infrastructure vendor and OS vendor perspectives, the general network 
operations community considers anything that makes Application Development 
harder to be "their problem". Persistent messages like "don't waste time on 
IPv6 development because we are only going to deploy IPv4 and I need shiny 
feature X NOW"  caused at least one decade of delay in infrastructure products 
doing anything. Now we appear to be stuck in another decade of delay based on 
"it is not exactly the same as IPv4". 

Like it or not, the OS vendors actually cater to the Application Developers, as 
they are the ones that produce something useful to the end user. Their job is 
to be the intermediary between the needs of the apps, and the availability (or 
lack) of network resources. (FWIW: as much as people on this list don’t like 
them this is exactly why I made sure XP did automated IPv6 over IPv4 tunneling) 
Fault the OS vendors if you want to, but they are often trying to make the 
networks appear more capable and consistent than they really are. To a first 
order this is the primary "innovation" of the iPhone, in telling the carriers 
"no you don't get to fragment the OS or application functionality". 

At the end of the day though, N = 1 is the most likely result of an NA 
deployment today. Once that engrained in the next generation of network 
operators, they will do everything they can to resist change, because their 
security architecture and all their tools assume N = 1 (or are we already 
there?). Taking the opportunity of change to also change the mindset toward PD 
allows N > 1. Enforcing an NA model where N > 1 eventually fails as N blows out 
the ND cache. 

Tony


> 
> 
> On Wed, Jun 10, 2015 at 12:29 PM, Lorenzo Colitti 
> wrote:
> 
> > On Thu, Jun 11, 2015 at 12:36 AM, Jeff McAdams  wrote:
> >
> >> Then you need to be far more careful about what you say. When you
> >> said "Android would still not support..." you, very clearly, made a
> >> statement of product direction for a Google product.
> >
> >
> > Did you intentionally leave the "in that scenario," words that came
> > right before the ones you quoted?
> >
> > How does a sentence that says "in that scenario, android would "
> > constitute a statement of direction?
> >
> 
> 
> 
> --
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network www.maineren.net

Re: Android (lack of) support for DHCPv6

[Matthew Huff]

+1

One IP per device will almost most likely be the preference and implementation 
in corporate/enterprise deployments. Too much procedure, regulation and other 
roadblocks prevent any other solution.

Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management, 
custom software, and other roadblocks will certainly stall if not stop IPv6 
deployments in enterprises if there isn’t at least the choice of static, single 
IPv6 addresses per device. SLAAC will probably be a complete non-starter in 
many corporate environments. It is in ours. The more ideologues preach about 
restoring peer-to-peer connectivity, dynamic IPs, privacy addresses, etc… the 
less penetration IPv6 will happen in corporate networks.



> On Jun 10, 2015, at 2:11 PM, Ray Soucy  wrote:
> 
> I've already written systems to do this kind of thing, but the logging
> requirements quickly go through the roof for a non-trivial network;
> especially in the case of temporary addressing now default on many
> systems.  That isn't so much the issue as operational consistency and
> supportability.
> 
> The requirement for hosts to be dual stack will exist for some time.
> 
> For the sanity of IT workers and users alike (most of which don't really
> know the details of IPv6 and barely understand address scopes let alone
> multiple addresses) there needs to be some level of consistency between how
> hosts are addressed and communicate between the two protocols.  Saying
> we'll develop one system for IPv4 and one for IPv6 ultimate results in
> "Let's not deploy IPv6 just yet".
> 
> This rings especially true when security concerns come up.  Consistency
> between IPv4 and IPv6 needs to be possible in this transition period, or
> people simply decide to not deploy.  Consistency in addressing and
> maintaining a one host one address model has major implications for policy
> construction, flow analysis and incident response, denial of service
> mitigation, etc.  If the consistency isn't there, you need to "re-invent
> the wheel" for every aspect, then maintain different systems for IPv4 and
> IPv6 along side one another.
> 
> Even worse, if we keep seeing adoption held up by inconsistent client
> implementations I fear we'll start seeing commercial products which NAT or
> proxy IPv4 to IPv6 to avoid using IPv6 internally.  It's very ugly and
> requires some DNS magic to work, but it's not impossible.  We're already
> seeing this in terms of cloud computing and virtualization.  Servers have
> IPv4 addresses and only a load balancer with an external IPv6 address.
> 
> We absolutely need to make it possible for people to adopt IPv6 before we
> can reach a point where IPv4 can go away, and for some organizations the
> answer of "Just use SLAAC" is simply not acceptable.
> 
> They just won't do it.
> 
> Preventing IPv6 adoption hurts us all.  And Android not supporting a MAJOR
> part of IPv6 like DHCPv6 is preventing adoption.
> 
> 
> 
> 
> 
> On Wed, Jun 10, 2015 at 1:42 PM, Sander Steffann  wrote:
> 
>>> 
>>> It's not the *only* option. There are large networks - O(100k) IPv6
>> nodes - that do ND monitoring for accountability, and it does work for
>> them. Many devices support this via syslog, even. As you can imagine, my
>> Android device gets IPv6 at work, even though it doesn't support DHCPv6.
>> Other universities, too. It's obviously  not your chosen or preferred
>> mechanism, but it does work.
>> 
>> /me starts to write that whitepaper that educates people on how to do this
>> 
>> Cheers,
>> Sander
>> 
>> 
> 
> 
> -- 
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network
> www.maineren.net

Re: Looking for information on IGP choices in dual-stack networks

[Robert Drake]

On 6/9/2015 11:14 AM, Victor Kuarsingh wrote:
We are looking particularly at combinations of the following IGPs: 
IS-IS, OSPFv2, OSPFv3, EIGRP.
If you run something else (RIP?) then we would also like to hear about 
this, though we will likely document these differently. [We suspect 
you run RIP/RIPng only at the edge for special situations, but feel 
free to correct us]. 


When we first were moving to IPv6 in the core network we evaluated IS-IS 
because it was what we were using for IPv4 and we would have preferred 
to run a single protocol for both.  We had problems with running a mix 
of routers where some supported IPv6 and others did not.  From what I 
recall, if any router did not support IPv6 then it wouldn't connect to a 
router running v6 and v4.


It's possible these were bugs and they were worked out later or just a 
messed up design in the lab, but we also like the idea of keeping IPv4 
and IPv6 away from each other so if one is broken the other one might 
still work.


So we use OSPFv3 for IPv6 routing and IS-IS for IPv4 routing.

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Lorenzo Colitti

> > On the other hand, there exist applications *today* that do require
> > DHCPv6. One such example would be MAP, which IMHO is superior to
> > 464XLAT both for the network operator (statlessness ftw) as well as
> > for the end user (unsolicited inbound packets work, no NAT traversal
> > required). MAP is provisioned with DHCPv6
> > (I-D.ietf-softwire-map-dhcp), so without DHCPv6 support in Android,
> > MAP support in Android is a non-starter.
> >
> 
> Support for the DHCPv6 protocol, or support for assigning addresses
> from IA_NA?

I'm not 100% certain, but you can possibly run MAP without IA_NA. But I
think you'll need the CE to be configured with a predictable IPv6
address so that the BR knows where to send the IPv6-encapsulated or
-translated IPv4 packets. I don't see how that would work with SLAAC.
But I'm not a MAP expert, so I'm open to be educated otherwise.

Anyway, here's a (hopefully constructive) suggestion on a way forward:

* Implement DHCPv6 client support (IA_NA, IA_TA, IA_PD .. the works)
* Upon network connection, request 2x IA_NA and 1x IA_PD (in addition
  to SLAAC):
** If you get addressing from SLAAC and/or IA_PD, accept the
   configuration and connect to the network.
*** If apps/services require additional addresses, self-assign them
from the on-link/delegated prefix as needed.
** If you get 2x IA_NA, accept the configuration and connect to the
   network.
*** If apps/services requires additional addresses, request additional
IA_NA as needed.
 If additional IA_NAs are declined either warn user or trigger
 Android's already existing «avoided bad network» functionality.
** If you get no SLAAC or IA_PD, and IA_NA <= 1, then refuse to
   connect to the network (or, for a dual-stack network, connect
   IPv4-only). (I.e., same behaviour as on a DHCPv6-only network
   today.)

Why N=2? Because it's >1, and what you seem to be worried about is
operators using N=1 without thought ("because that's what we did in
IPv4"). N=2 will confirm that's not the case for the given network, so
I think confirming N=2 gives a much stronger indication that the
network allows N= than confirming N=1.

That said, I doubt that you can rely on the network accepting
N=, neither for DHCPv6 IA_NA *nor* SLAAC, due to
neighbour table limitations and DAD overhead (both delay and packets).
If the future applications we're imagining needs IPv6 addresses in that
ballpark (which isn't *that* far-fetched - say a new address per
connection, process, app, whatever), IA_PD is the only mechanism we have
today that will work. If you start supporting IA_PD, my bet networks
are going to start offering it - just like when you added 464XLAT.

Tore

Re: Android (lack of) support for DHCPv6

[Tore Anderson]

* Dave Taht

> I am told that well over 50% of all android development comes from
> volunteer developers so rather than kvetching about this it seems
> plausible for an outside effort to get the needed features for
> tethering and using dhcpv6-pd into it. If someone wanted to do the
> work.

https://android-review.googlesource.com/#/c/78857/

Tore

Re: Lists of VPN exit addresses?

[Tyler Mills]

I'd imagine it is quite easy for a lot of these providers to have a
pre-configured virtual machine template or cd image that they can deploy
across the board amongst a plethora of different VPS solutions as well.
Being able to bring up exit points on the fly would be very helpful in
bypassing censorship.

On Wed, Jun 10, 2015 at 12:39 PM Bacon Zombie  wrote:

> Well if they are using Hola then EVERY person with it installed is an
> exit-node.
>
> http://adios-hola.org
>
>
> https://m.reddit.com/r/netsec/comments/37rit3/adios_hola_why_you_should_immediately_uninstall/
> On 10 Jun 2015 14:28, "Jared Mauch"  wrote:
>
> >
> > > On Jun 10, 2015, at 8:08 AM, Roland Dobbins 
> wrote:
> > >
> > >
> > > On 10 Jun 2015, at 18:56, John Levine wrote:
> > >
> > >> I presume there is no need to explain why this would be of interest.
> > >
> > > To keep consumers who've legitimately purchased/rented/subscribed to
> > content from accessing same when they travel internationally?
> > >
> > > Because as a regular international traveler, that's what springs to
> mind
> > when I see requests like this.
> > >
> > > Another thought is governmentally-driven censorship, something else I
> > encounter a lot in my travels.
> >
> > I’ll just simplify this and say that the Tor Project publishes a list of
> > its exit nodes so you can block these if your abuse/fraud requirements
> > necessitate this.
> >
> > https://check.torproject.org/cgi-bin/TorBulkExitList.py
> >
> > If it’s for geolocation blocking, I’m in favor of these political
> > limitations to go away.  It doesn’t take a genius to bypass these if
> that’s
> > your intent.
> >
> > - Jared
>

Re: Android (lack of) support for DHCPv6

[Florian Weimer]

* Lorenzo Colitti:

> I think what I said is that supporting DHCPv6-only networks will eventually
> force OS manufacturers to implement IPv6 NAT. This is because there are
> many features inside a mobile OS that require multiple IP addresses.

On many networks, there will be fairly tight limits on the number of
usable addresses per “port” even with SLAAC, similar to the evolution
of Ethernet switching, which led to configurable limits of MAC
addresses per port.  So you'll likely need IPv6 NAT in the future
anyway.

Re: Android (lack of) support for DHCPv6

[Josh Reynolds]

Memory is cheap, ASICs and FPGAs are getting better all the time.

It might be a problem a few years from now for older hardware, but I 
can't see it causing real issues long term.


Josh Reynolds
CIO, SPITwSPOTS
www.spitwspots.com

On 06/10/2015 12:42 PM, Florian Weimer wrote:

* Lorenzo Colitti:


I think what I said is that supporting DHCPv6-only networks will eventually
force OS manufacturers to implement IPv6 NAT. This is because there are
many features inside a mobile OS that require multiple IP addresses.

On many networks, there will be fairly tight limits on the number of
usable addresses per “port” even with SLAAC, similar to the evolution
of Ethernet switching, which led to configurable limits of MAC
addresses per port.  So you'll likely need IPv6 NAT in the future
anyway.

Greenfield 464XLAT (In January)

[Nicholas Warren]

Sincere apologies if this e-mail is inappropriate for this audience,
We are (going to be) a startup ISP building a new network from the ground up. I 
was hoping I could get an opinion, or two, on how everyone feels about 464XLAT. 
I saw what everyone was saying about it in the 'Android doesn't support DHCPv6' 
discussion, but what about in the wireline side of things? The main reason we 
are even considering 464XLAT as opposed to dual-stack (the latter is, in my 
ignorant opinion, the better option.) is the fear of IPv4 depletion that we 
think might hit ARIN between now and the start of next year; causing us to pay 
a premium for IPv4 in the gray market. So I guess the real question here would 
be: is our fear real, or is it just bug on the wall? If our fear is real, what 
should we implement so that our users can still get to the v4 internet, are we 
even thinking soberly by suggesting 464XLAT?
Thanks,
- Nich

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 11:51 AM, Matthew Huff  wrote:

> +1
>
> One IP per device will almost most likely be the preference and
> implementation in corporate/enterprise deployments. Too much procedure,
> regulation and other roadblocks prevent any other solution.
>
> Authentication, Authorization, Accounting, ACLS, NMS, IDS, IP management,
> custom software, and other roadblocks will certainly stall if not stop IPv6
> deployments in enterprises if there isn’t at least the choice of static,
> single IPv6 addresses per device. SLAAC will probably be a complete
> non-starter in many corporate environments. It is in ours. The more
> ideologues preach about restoring peer-to-peer connectivity, dynamic IPs,
> privacy addresses, etc… the less penetration IPv6 will happen in corporate
> networks.
>
>
> So, the critical piece of what you assert above appears to be "static",
not "single".  If a local address management system is always configured to
hand out the same /N to the same device, there doesn't seem to be a
requirement in the above that N=1.

Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat
or which might want to tether other devices; he's volunteered to work with
folks on a document and to write code for the case where a device
successfully gets a useful value of N>1.

Can you help me understand why that doesn't work for you?

On the related topic of privacy addresses, I believe we should all be ready
for increasing variability in MAC address emitted by devices, and that if
you are intending to use MAC auth to assign that /N, you may now  be or
will soon be surprised.  In addition to the work Apple has done and which
can be done with Android, see the IEEE work here:

http://www.ieee802.org/PrivRecsg/

regards,

Ted

Re: Android (lack of) support for DHCPv6

[Ricky Beam]

On Wed, 10 Jun 2015 00:58:06 -0400, Lorenzo Colitti   
wrote:

On Wed, Jun 10, 2015 at 12:26 PM, Jon Bane  wrote:

DHCPv6 - RFC3315 - Category: Standards Track
464XLAT - RFC6877 - Category: Informational


Ooo, that's fun, can I play too?


We aren't asking you to support BGP, or SNMP. We're DEMANDING you support  
a FUNDAMENTAL COMPONENT of IPv6. DHCPv6 is not *optional*. And every  
reason you've given to date sounds like a whiny I-Don't-Like-It political  
agenda. The fact that others have made it work is proof of your  
asshattery. This has been going around for **YEARS**. You've spent orders  
of magnitude more time defending your "no" position than it would take to  
actually include DHCPv6 support. In *two days* of bitching on NANOG, every  
one of your positions has been shot down, and solutions to every corner  
case has been presented -- sure, the network policy could still render  
things non-workable (no PD, only one address, etc.)


Will IPv4 only apps work with only one v6 address, no. (or "not easily")  
But then, IPv4 isn't IPv6; any kludge to get one to work within the other  
is 100% BS hackery (because no one thought about migration or  
interoperability. dual-stack was declared the answer, and the WG patted  
themselves on the back.)


Given the choice of ZERO network access, or ("legacy" ???) IPv4 only apps  
not working, I'll take the later. The people in charge of those lacking  
apps need to fix their shit.

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 2:00 PM, Ted Hardie wrote:

Lorenzo has detailed why N=1 doesn't work for devices that need to use xlat


... and it's been well demonstrated that this is a red herring argument 
since the provider has to configure xlat for it to have any chance of 
working.



or which might want to tether other devices;


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

I'm not a fan of N=1 for IPv6, but none of Lorenzo's arguments hold water.


--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Tuesday, June 09, 2015 7:49 PM
> 
> That sounds pretty stupid even for me, so probably something got lost in
> translation.

"Implementing stateful DHCPv6 would break planned use cases such as IPv6 
tethering"

"And it's not possible to enable tethering"

"tethering cannot be made to work well"

"what do you expect Android to do if given only one IPv6 address and the user 
turns on tethering"

'Saying "tethering is not available" is not going to fly'

Yes, while you have mentioned a few other things, based on your postings on the 
issue thread tethering seems to be one of your hot topics.

> I think what I said is that supporting DHCPv6-only networks will eventually 
> force
> OS manufacturers to implement IPv6 NAT.

As opposed to not supporting DHCPv6 operation forcing users to adopt phones 
based on operating systems other than android?
 
> You don't "have to do" SLAAC and RDNSS. For as long as the network provides
> IPv4, there won't be a problem for anyone.

Thank you very much for being the guy in charge of determining what my problems 
are.

As I already mentioned in the issue thread, one of our motivations for moving 
forward with IPv6 deployment is that some grants our faculty want to apply for 
require native IPv6 communication. So an android device that is incapable of 
connecting to our IPv6 network due to deficiencies in its implementation of 
IPv6 standards will not be usable for that grant work. But I will be sure to 
tell the faculty that the android developer responsible for that breakage 
assures them it is not a problem. After which I will encourage them to switch 
to another platform which provides for its users' needs rather than its 
developers' crusades.

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 8:15 AM, Ray Soucy wrote:

The statement that "Android would still not implement DHCPv6 NA, but it
would implement DHCPv6 PD." is troubling because you're not even willing to
entertain the idea for reasons that are rooted in idealism rather
than pragmatism.


I was going to respond on this issue in more depth, but others have 
already gotten there ahead of me. I think Ray's paragraph above sums it 
up best.


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/9/15 1:27 PM, Joel Maslak wrote:

Agreed - apparently the solution is to implement SLAAC + DNS advertisements
*AND* DHCPv6.  Because you need SLAAC + DNS advertisements for Android, and
you need DHCPv6 for Windows.

Am I the only one that thinks this situation is stupid?


No, you're not. Some of us have been saying that requiring RA is a bad 
idea, and that adding features to it is a bad idea, for over 15 years now.


Unfortunately the anti-DHCP crowd hasn't budged, no matter how many 
operators have told them that they cannot manage an IPv6 network with 
the current state of the protocol.


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Tuesday, June 09, 2015 11:33 PM
>
> value of N. I'd be happy to work with people on an Internet draft or other
[...]
> It's also possible for Android to support DHCPv6 PD. Again I'd be happy to
> work with people on a document that says that mobile devices should do

It would be nice if you were happy to work with people on actually implementing 
what they are asking for and what their users need as opposed to just methods 
to try and twist the world to your personal viewpoint.

Or maybe even just merging work somebody already did well over a year ago?

https://android-review.googlesource.com/#/c/78857/

> 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.

Absolutely; having a device incapable of connecting at all is a *much* better 
user experience. Have you ever met a user 8-/?

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton  wrote:

> On 6/10/15 2:00 PM, Ted Hardie wrote:
>
>> Lorenzo has detailed why N=1 doesn't work for devices that need to use
>> xlat
>>
>
> ... and it's been well demonstrated that this is a red herring argument
> since the provider has to configure xlat for it to have any chance of
> working.
>
>  or which might want to tether other devices;
>>
>
> ... 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.  :)​
>

​The other option would, of course, be "bridging" plus IPv6 "NAT", and I
assume you see the issues there.​

​Back to the question I asked before:  does "static" solve the stated
problems without "single"?

regards,

Ted​

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Mikael Abrahamsson
> Sent: Wednesday, June 10, 2015 12:05 AM
> 
> You seem to fail to realise that you are not Lorenzos customer, his
> customer is the OEMs that build mobile phones, and their customers who buy
> Android phones.

And he fails to realize that the people who buy android phones actually want
them to work. And the companies manufacturing android phones want their
users to be satisfied. And when every single mobile phone other than an
android phone does seem to work, who do you think they're going to blame? I
can already tell you our helpdesk response "Unfortunately, the android
operating system does not fully implement IPv6 standards and as such is not
capable of interoperating with our network. Consider switching to an iPhone,
or a Windows Phone, or a [every other phone that works]."

> So while you are doing what you think is best for your network, Lorenzo is
> doing what he thinks is best for his platform and the hundreds of millions
> of Android users that are out there.

I am sure all of those millions of users sleep better at night knowing that
omniscient and caring Lorenzo is looking out for their long-term interests
while denying them short-term usability.

> So I happen to agree with Lorenzo that a single IA_NA per device world is
> a crippled world. Lorenzo said he was willing to work on a document that
> creates a recommendation for certain minimum amount of IPv6 addresses per
> device and/or PD, so let's get that happening then?

How about we support existing already widely deployed Internet standards so
they can be used while future standards are being developed?

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Ray Soucy
> Sent: Wednesday, June 10, 2015 4:36 AM
> 
> In practice, your device will just not be supported.
[..]
> If your client is broken because of an incomplete implementation, I just
> won't give it an IPv6 address at all.  I think a lot of others feel the
> same way.
[...]
> already provide ubiquitous wireless coverage.  I don't want users enabling
> a hotspot (rogue AP) on campus because it has a negative impact on service
> for others, so the whole argument is really meaningless in the context of
> higher education and campus networking.

Yes. That. All of that. I think you'll find a lot of higher education 
institutions will agree with this viewpoint.

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 5:07 AM
> 
> getting rid of NAT. Today in IPv4, tethering just works, period.
[...]
> IPv4-only apps always work.

Wow. If your phone just "always works", you certainly lead a charmed life.

> A model where the device has to request resources from the network before
> enabling tethering, or before supporting IPv4-only apps, provides a much
> worse user experience. The user might have to wait a long time, or the
> operation might even fail.

Far better that the user stare at the useless android brick in their hand that 
is incapable of connecting to the network at all.

Maybe you should try taking a poll of actual users? Dear user, would you rather:

A) have a phone that connects to the network and the most part works barring 
some side cases

B) have a phone that is incapable of connecting, but saves you from being 
unable to use certain functionality that otherwise would have been unavailable. 
By preventing you from using any functionality at all.

Re: Android (lack of) support for DHCPv6

[Doug Barton]

On 6/10/15 2:27 PM, Ted Hardie wrote:



On Wed, Jun 10, 2015 at 2:16 PM, Doug Barton mailto:do...@dougbarton.us>> wrote:

On 6/10/15 2:00 PM, Ted Hardie wrote:

Lorenzo has detailed why N=1 doesn't work for devices that need
to use xlat


... and it's been well demonstrated that this is a red herring
argument since the provider has to configure xlat for it to have any
chance of working.

or which might want to tether other devices;


... 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.  :)​


I saw that, he was refuted by others, most notably by the simple fact 
that bridging works now in IPv4, so obviously there is a way to make it 
work.


I think PD is the right answer here of course, but that doesn't mean 
that bridging is the wrong answer.



​The other option would, of course, be "bridging" plus IPv6 "NAT", and I
assume you see the issues there.​


No, actually I don't. I realize that you and Lorenzo are part of the 
rabid NAT-hating crowd, but I'm not. I don't think it's the right answer 
here, but I don't think it's automatically a problem either.



​Back to the question I asked before:  does "static" solve the stated
problems without "single"?


It *could*, but Lorenzo actually does have a point when he talks about 
not wanting to cripple future application development. I'd also like to 
see a rough outline of an implementation before commenting further.


Meanwhile, DHCPv6 + PD solves all of Lorenzo's stated problems, but he 
won't implement it because "DHCP." That's not something you can engineer 
around.


Doug

--
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!




signature.asc
Description: OpenPGP digital signature

Re: Android (lack of) support for DHCPv6

[Mark Andrews]

In message 
, Ray Soucy writes:
> The whole conversation is around 464XLAT on IPv6-only networks right?
> We're going to be dual-stack for a while IMHO, and by the time we can get
> away with IPv6 only for WiFi, 464 should no longer be relevant because
> we'll have widespread IPv6 adoption by then.

Or just support DS-Lite along with DHCPv6.

DS-Lite does not require its own IPv6 address.
464XLAT and DS-Lite both limit IPv4 packet sizes to less than native.
DS-Lite works with DNSSEC.  DNS64 doesn't.
DS-Lite doesn't require mucking with packet contents.
DS-Lite doesn't result in sites being unreachable just because the IPv6
instance is down which is a side effect of DNS64.
 
> Carriers can do IPv6 only because they tightly control the clients, for
> WiFi clients are and will always be all over the place, so dual stack will
> be pretty much a given for a long time.
> 
> 
> On Wed, Jun 10, 2015 at 9:50 AM, George, Wes 
> wrote:
> 
> >
> > On 6/10/15, 2:32 AM, "Lorenzo Colitti"  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 especiall=
> y
> > 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/enabl=
> e
> > 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=E2=80=99s mail serv=
> er, 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 th=
> at
> > 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 o=
> f
> > this E-mail and any printout.
> >
> 
> 
> 
> --=20
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> 
> T: 207-561-3526
> F: 207-561-3531
> 
> MaineREN, Maine's Research and Education Network
> www.maineren.net
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 5:22 AM
> 
> It's certainly a possibility for both sides in this debate to say "my way
> or the highway", and wait and see what happens when operators start
> removing support for IPv4.

You are rather confused.

Only one side of this debate is saying "my way or the highway" – yours.

On my side, I am saying that it is my network, and it is not only my right but 
my responsibility to define policies as to how it should be used. That could be 
by blocking port 25 outbound to prevent spam abuse, or by forbidding 
unauthenticated wireless access points, or by requiring WPA2-enterprise 
authentication to connect, or any other technical configuration determined to 
be needed or desired by our policy. Can anyone reasonably say that a provider 
of a network is not allowed to determine the policies by which that network 
must be used 8-/?

On the other hand, *you* are providing infrastructure. You are refusing to 
implement agreed-upon Internet standards that are already widely supported. You 
are trying to determine what policy we should use on our network. It is 
completely different. I'm sorry you cannot see that.

> But even if you're dead set on using DHCPv6, what I don't see is why don't
> you support DHCPv6 PD instead of IA_NA?

Perhaps we will support it in addition to. Or perhaps we will not support it at 
all as that use pattern might not be desirable on our network. However, I am 
quite certain all of the equipment we purchase and recommend to purchase will 
support both standards, as well as SLACC and all other standards that have been 
defined as a base part of IPv6 support. As providers of infrastructure should. 
And then we will choose which of them to deploy. As managers of networks should.

> more than one IPv6 address and cannot be done without that. We know these
> will break today; tomorrow, we can use multiple addresses to do things we
> haven't thought of yet.

Who knows, maybe IPv12 will solve all of these issues? Maybe we shouldn't 
bother trying to deploy IPv6 while we're waiting for somebody to design and 
implement IPv12.

Re: Android (lack of) support for DHCPv6

[Ted Hardie]

On Wed, Jun 10, 2015 at 2:36 PM, Doug Barton  wrote:

>
>
>>
>
>  ​The other option would, of course, be "bridging" plus IPv6 "NAT", and I
>> assume you see the issues there.​
>>
>
> No, actually I don't. I realize that you and Lorenzo are part of the rabid
> NAT-hating crowd, but I'm not. I don't think it's the right answer here,
> but I don't think it's automatically a problem either.
>

​So, I don't think I'm particularly rabid about this, but I have dealt for
a long time on the application side with the side effects.  Anyone who has
had to engineer a system that requires STUN/TURN/ICE can tell you that it
is pretty much a dancing bear.  The wonder is how sweetly the bear dances,
but that it dances at all.  If one of the things I'm tethering wants to do
RTCWEB, it's going to be painful if it doesn't have its own address,
because it will need to hairpin out to do STUN at the very least.​


>  ​Back to the question I asked before:  does "static" solve the stated
>> problems without "single"?
>>
>
> It *could*, but Lorenzo actually does have a point when he talks about not
> wanting to cripple future application development. I'd also like to see a
> rough outline of an implementation before commenting further.
>

​That's fair enough, and some variability in what N is depending on device
is as a well.  But understanding whether what we're actually looking for is
"static" or "single" is a pretty key piece of the requirements scoping, and
it sounds like "static" is it, at least from your perspective.  Is that a
fair assessment?

regards,

Ted​




>
> --
> I am conducting an experiment in the efficacy of PGP/MIME signatures. This
> message should be signed. If it is not, or the signature does not validate,
> please let me know how you received this message (direct, or to a list) and
> the mail software you use. Thanks!
>
>

Re: Greenfield 464XLAT (In January)

[Ca By]

On Wed, Jun 10, 2015 at 1:22 PM, Nicholas Warren 
wrote:

> Sincere apologies if this e-mail is inappropriate for this audience,
> We are (going to be) a startup ISP building a new network from the ground
> up. I was hoping I could get an opinion, or two, on how everyone feels
> about 464XLAT. I saw what everyone was saying about it in the 'Android
> doesn't support DHCPv6' discussion, but what about in the wireline side of
> things? The main reason we are even considering 464XLAT as opposed to
> dual-stack (the latter is, in my ignorant opinion, the better option.) is
> the fear of IPv4 depletion that we think might hit ARIN between now and the
> start of next year; causing us to pay a premium for IPv4 in the gray
> market. So I guess the real question here would be: is our fear real, or is
> it just bug on the wall? If our fear is real, what should we implement so
> that our users can still get to the v4 internet, are we even thinking
> soberly by suggesting 464XLAT?
> Thanks,
> - Nich
>
>
Yes, your fears about IPv4 are correct.

If you have a look at ARIN PPML lately, you can see some pretty intense
"discussion" about companies exporting ARIN addresses to CCNIC and so on.

As a greenfield, you should definitely be focused on IPv6-only to the edge
solutions.  DS-lite, MAP-E, and 464XLAT come to mind.

DS-lite is the oldest and most common in wireline.  464XLAT is more common
in mobile. MAP-E and MAP-T have not yet been deployed at the same scale as
DS-lite and 464XLAT yet AFAIK, not sure if they will be.

You could also simply do dual-stack with private space and CGN to the end
user using RFC1918 (10.0.0.0/8,  100.64.0.0/10)

Regards,
CB

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Ray Soucy
> Sent: Wednesday, June 10, 2015 6:06 AM
>
> As for thinking "long term" and "the future", we need devices to work
> within current models of IPv6 to accelerate _adoption_ of IPv6 _today_
> before we can get to that future you're talking about.
> 
> Not supporting DHCPv6 ultimately holds back adoption, which makes people
> see IPv6 as optional for longer, and discourages deployment because vendor
> support is all over the place and seen as "not ready".
> 
> This isn't theory, we've been _living_ with this as a reality for years
> now.  The networks are ready; the clients are not.
> 
> Universities see a constant stream of DMCA violation notices that need to
> be dealt with and not being able to associate a specific IPv6 address to a
> specific user is a big enough liability that the only option is to not use
> IPv6.  As I said, Android becomes a second class citizen on the network
> under your model.

Your ideas are intriguing to me and I wish to subscribe to your newsletter ;).

When someone shows up with a device that only supports WEP, or doesn't support 
WPA2-Enterprise, we tell them they need to replace it with a device supporting 
current standards that provide the minimum level of security we have decided 
upon for our network policy. When someone shows up with an android device that 
can't connect to our IPv6 network, we will tell them to replace it with a 
device that fully supports current standards.

I still find it hard to believe that Google as a corporate entity thinks it is 
more important to try and force network operators to conform to their ideals 
for configuration than it is to make android feature equivalent with its 
competitors.

Also seeking transit in Equinix SV2/Santa Clara (was: Re: RFP for Internet Transit for ARIN ASN 394018)

[John Curran]

Folks -

I forgot to mention the second west coast Internet transit RFP for
delivery at Equinix SV2 - 


Thanks!
/John

On Jun 9, 2015, at 9:23 AM, John Curran 
mailto:jcur...@arin.net>> wrote:

Hello NANOG Folks -

   Apologies for the distraction, but ARIN needs some transit providers and I 
thought
   there may be one or two on this list...

   We need 1 GB via standard multi-mode fiber in Wowrack/Seattle - ISP must 
provide
   native IPv4 and IPv6 connectivity, provide full view of the IPv4 and IPv6 
routing table,
   support 32-bit ASNs, etc.

   If interested, please review the full RFP for details and response 
information.

Thanks!
/John

John Curran
President and CEO
ARIN

Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] RFP for Internet Transit for ARIN ASN 394018
Date: June 9, 2015 at 8:59:07 AM PDT
To: 
mailto:arin-annou...@arin.net>>

ARIN is soliciting proposals from Internet Service Providers (ISPs) to bid on 
the delivery of Internet transit to ARIN's network, ASN 394018. This network is 
part of ARIN's provisioning network and is a part of critical Internet 
infrastructure. ARIN is looking for qualified providers that are able to 
provide service to its rack within Wowrack's datacenter located in Tukwila, 
Seattle.

All contractual terms and conditions related to the work performed, 
nondisclosure of information, or liability issues must be detailed. ARIN will 
require that the vendor performing this service sign a nondisclosure agreement 
due to the proprietary nature of the information ARIN retains for its 
subscribers.

All proposals must be submitted no later than 5:00 p.m. EDT on 22 June 2015. 
ARIN will evaluate the properly submitted proposals and will select a winning 
bidder or bidders no later than 30 June 2015.

Full text of the RFP is available at:
http://www.arin.net/about_us/contracts/201506-westcoast-transit-rfp-sea.pdf

Send proposals to rfp-transit-...@arin.net or by mail to:

Matt Rowley
Infrastructure Manager
ARIN
3635 Concorde Parkway, Suite 200
Chantilly, VA. 20151
ATTN: Proposal for Internet Transit Services

Technical questions may be directed to:
rfp-transit-...@arin.net

ARIN is operated as a nonprofit 501(c)(6) corporation which is chartered for 
educational, charitable, and scientific purposes. It is a membership 
organization with an official IRS designation as a business league.
___

RE: Android (lack of) support for DHCPv6

[Paul B. Henson]

> From: Lorenzo Colitti
> Sent: Wednesday, June 10, 2015 8:27 AM
> 
> please do not construe my words on this thread as being Google's position
> on anything. These messages were sent from my personal email address, and I
> do not speak for my employer.

Can we construe your postings on the issue thread as being Google and/or 
Androids official position? They are posted by lore...@google.com with a tag of 
"Project Member", and I believe you also declined the request in the issue 
under that mantle.

If your postings on the issue thread are not authoritative for Google, could 
you possibly put us in contact with who as Google could make an official 
statement as to why they are refusing to implement an accepted Internet 
standard already deployed by their competitors, the lack of which will directly 
harm their users?