Subject: Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08

From: "Byrne, Cameron" <[email-masked]>
Date: Fri, 30 Nov 2012 19:26:27 -0800

Ted,

Thanks for taking the time to review our work.  My comments in-line.

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Friday, November 30, 2012 1:15 PM
> To: [email-masked]; [email-masked]
> Subject: Review of draft-ietf-v6ops-464xlat-08
> 
>  I have been selected as the Applications Area Directorate reviewer for this draft
> (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
> 
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> Document:draft-ietf-v6ops-464xlat-08
> Title: 464XLAT: Combination of Stateful and Stateless Translation
> Reviewer: Ted Hardie
> Review Date: November 30, 2012
> 
> Summary: This draft is not ready for publication as a BCP, and it may not be an
> appropriate candidate for this status.
> 
> Major Issues:
> 
> This document provides a v4/v6 inter-working method using a pair of address
> translators that bracket a network region in which there is no
> IPv4 routing.  It discusses two different potential deployments.  In the first, the
> first address translator is co-resident on the device where the IPv4 address is
> assigned; in the second, the the first address translator is resident in a nearby
> network device.  In both, the second address translator is at the border of the
> internal IPv6 routing domain and a global IPv4 routing domain.
> 
> The document has the following applicability statement:
> 
>    This BCP only applies when the following two criteria are present:
> 
>    1.  There is an IPv6-only network that uses stateful translation
>        [RFC6146] as the only mechanism for providing IPv4 access.
> 
>    2.  There are IPv4-only applications or hosts that must communicate
>        across the IPv6-only network to reach the IPv4 Internet.
> 
> The first item is problematic.  This document describes a method for using
> stateful translation, but it does not justify why this is the appropriate choice; the

The choice for using a stateful translator is outside the scope of this document.  

But, the IETF has published RFC 6146 which is specifies a stateful protocol translator on the standards track.  RFC6146 is necessary but not sufficient to operate an IPv6-only network that is dominated (today) by IPv4 nodes.  The problem of IPv4-referals / IPv4-literals as well as IPv4 sockets APIs is very real.  It would be very unfortunate if the IETF specified stateful NAT64 in RFC 6146 but was no deployable or could only provide an 85% service (15% of Android apps fail to work on NAT64/DNS64 only networks)

Just generally speaking on why stateful is the right choice, many networks already operate stateful NAT44 and the NAT64 is just another feature that is quick to deploy on existing hardware with existing support models.  Furthermore, this architecture is based on the reality that IPv4 address are no longer available in APNIC in blocks larger than an emergency /22 (RIPE and ARIN also have max /22 allocations for the last /8 in the RIR).  That said, stateful multiplex of ports / sessions is absolutely required for any service that must scale to millions of users.  Stateless solutions simply do not scale for new entrants that do not have existing IPv4 resources.

> encapsulation methods used in something like DS-Lite seem to be an alternative
> here, and it is not clear either what constraint prevents encapsulation's use in
> these networks or what the advantage is here to using dual translation over an
> encapsulation-based method.  In other words, this appears circular--it defines it

Encapsulation can break many things including traffic engineering based on IP address (no more hop by hop routing), DPI associated with charging (specifically 3GPP defined Policy and Charging Controls (PCC)).

DS-lite also has configuration driven exclusively by DHCP, there is no DHCP in 3GPP networks.

> as a best practice for networks using stateful translation, rather than defining
> when stateful translation is best practice.
> 

The wording of the document was chosen to state the circumstance that you have this type of network:  IPv6-only with stateful NAT64 as defined here http://tools.ietf.org/html/rfc6144#section-2.1  Given that scenario, there is a practical reality that hosts and software have specific IPv4 dependencies and thus this scenario is defunct without something like 464XLAT. And, that goes origins of 464XLAT.  It is emergent behavior that occurs in my IPv6-only network at T-Mobile USA.  People wanted Skype to work so they put an NAT46 on the host ....and Skype now worked.

We track broken Android apps at this list (15% don't work:  Skype, Netflix, Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z3j3q

464XLAT allows for the real commercial deployment of IPv6-only networks.

The current state of the network at T-Mobile USA today is squat space + NAT44.  This is the same at Rogers and Sprint mobile networks here in North America.

> The document also says this in the introduction, which provides an additional
> applicability
> limitation:
> 
>    The 464XLAT architecture only supports IPv4 in the
>    client server model, where the server has a global IPv4 address.
>    This means it is not fit for IPv4 peer-to-peer communication or
>    inbound IPv4 connections
> 
> If this is true, it is highly problematic, because it provides a constraint on the
> semantics of an RFC 1918 address that is not currently present.  It is not entirely
> clear, though, that this is true.
> 
> Systems attempting peer-to-peer communication when using RFC 1918
> addresses typically must use ICE to handle the artifacts of network address
> translation.
> I was not able to understand
> how ICE would fail here, either in the case where the CLAT was resident on the
> node or when it is network resident.  In my naive reading, this would work for
> cases where the ICE server was in the IPv4 global routing domain.  Because
> PLATs are provisioned with a single IP address, the mapped address attribute

What do you mean 1 IP address?  1 IPv4 address?  They will have pools of address for sure.

> would always have the same family and address, but it seems it should be
> distinguishable by port.  If this is not the case, or there is a different reason why
> this mechanism cannot work with ICE, I believe it should be called out in the
> draft explicitly.
> 

We make this restriction because of the case where you and I are on the same ISP.  We both have 10.10.10.1  as our local address. Communication fails.

If we have unique address space, are right, it would work.  But, we do not want to push an additional level of complexity to try and coordinate unique LAN side IP addresses.  It is simpler to say this simply does not work.  And, in case of DNS64, users will generally not use IPv4.  IPv4 is only used for the case of IPv4 referals or IPv4-only host and APIs.

> An ICE-based peer-to-peer connection would, certainly, provide a severely sub-
> optimal path for two devices within the same 464xlat region, as it would hairpin
> out and back. But those are not the only potential peer-to-peer connections and
> it would work at least to some degree.
> 
> In the case where the CLAT is resident on a device, but that device provides
> tethering, the document currently says:
> 
>            The CLAT SHOULD perform router function to
>            facilitate packets forwarding through the stateless
>            translation even if it is an end-node.
> 
> For proper operation of tethered devices, this would appear to require a MUST,
> rather than a SHOULD.
> If it is not MUST, then some description of what will happen is desirable.
> (Perhaps a statement that CLATs which do not provide this functionality cannot
> be used when tethering is in place or whether tethered devices require IPv4?)
>

I think you are right.  We can do a must here.
 
> Minor Issues:
> 
> This draft is currently targeted for BCP.   I do not believe that it
> is appropriate to target it for

The rational is that 464XLAT is a best practice for RFC 6144 2.1 network that has IPv4-only apps in it.

> BCP  unless it is preferred over encapsulation-based approaches.  I also believe
> that the marketing material which is currently embedded in the text (see, for
> example, section 5) should be removed.
> 

I am happy to eliminate section 5, but section 5 has been required during draft formation because there are many solutions in this space.

> Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9", but
> there is no citation given.  I also note that 3GPP specifications currently appear

See RFC6459

> to be on release 12, and there is no notice of whether changes between pre-

The most advanced LTE network is Release 8 at Verizon.

Most  phones are release 7 or earlier (sold on the market today)

New networks like the one T-Mobile will launch next year will be partially Release 10

> release 9 and the current release have changed the topology in a way to

Current release is not relevant to install base.

> eliminate the multiple PDP issue raised.  If the text means to say that this is not a

But it does not remove the dependency on IPv4 address that are not available.... public and private addresses are both exhausted, so we use squat space.

> problem for any version 9 or later, and that the problem exists for any version
> prior to 9 which supports multiple address families, it needs to be reworded.

I will review the wording.  Thanks again for your review.  I look forward to more feedback from you, thanks again for taking the time to work with us and sharing your experience

Thanks
Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 2 Dec 2012 19:56:13 -0800

Ted,

i have revision to my previous statements

>> it would work at least to some degree.

I believe you are right that ICE would work at the app level.

Our statement about hub-and-spoke in the I-D was driven by wording set
in http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2

In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes
via the NAT64 can communicate with other IPv4 nodes.  That is the
basic architecture, if you need IPv4 access, send it via the CLAT and
PLAT where CLAT is the spoke and PLAT is the hub

Our claim that p2p does not work is based on the topological case that
if you are address 2001:DB8:9999::10.1.1.1 and i am address
2001:DB8:8888::10.1.1.1  our ipv4-only nodes behind the CLAT cannot
send packets to each other without something like ICE to force them
via the NAT64 or TURN.

If our addresses were different on the LAN like
2001:DB8:9999::10.1.9.9 and   2001:DB8:8888::10.1.1.1 we could send
IPv4 packets to each other without the need for the hub (PLAT) since
each CLAT would do RFC 6145 translation and remove the first 96 bits
on the  LAN side.  This is great if there is a high chance that the
LAN side IPs are unique, but that is not the case and result would be
ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1

The current wording in question is "The 464XLAT architecture only
supports IPv4 in the
   client server model, where the server has a global IPv4 address.
   This means it is not fit for IPv4 peer-to-peer communication or
   inbound IPv4 connections."

The important term is "fit" vs "not fit".  Given that path would go
via a hub and may require ICE in the apps and infrastructure, it would
not really be direct p2p, and therefore the WG settle on this specific
language to error on the side of caution to the reader that this is
not a "fit" design if p2p is an important use-case in ipv4 supporting
ipv4.  The current statement is a caution to the reader and that is
the reason it appears in the introduction.

Alternatively, we can strike this from the introduction all together
and give a more in-depth discussion that reference ICE for the p2p
case.  The WG decided it was best to just punt on p2p and say it does
not work here in the introduction.

CB

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Dec 2012 10:01:39 -0800

> Thanks for taking the time to review our work.  My comments in-line.

Hi Cameron,

Thanks for the quick reply; some additional questions/comments in-line
with yours.

regards,

Ted

> But, the IETF has published RFC 6146 which is specifies a stateful protocol translator on the standards track.  RFC6146 is necessary but not sufficient to operate an IPv6-only network that is domin…

I apologize, it appears I did not express this well. I was trying to
get at the question of why using stateful translation in cases where
there is no IPv4 routing domain is the right idea. My understanding of
RFC 6146 is
that is specifies a method for allowing IPv6 only clients to reach a
v4 Internet host; it does not seem to require the creation of separate
technique to allow nodes to retain an IPv4 address in networks that do
not have IPv4 routing.  That may well be justified by something else,
but I don't personally see how RFC 6146 justifies or requires it.

You mention that the use of IPv4 referrals or literals are a part of
this problem.  I understand that, but I'm not
honestly note sure that I understand how creating a method that makes
nodes believe that they are part of a
local IPv4 routing domain when they are actually only part of a v6
local routing domain (and via that a global
v4 routing domain) actually helps.  It seems particularly worrisome if
they have to understand some set of
limitations (even if you got a 464xlat socket option, it's not stated
how a node would know over what networks it would have to use it).

> DS-lite also has configuration driven exclusively by DHCP, there is no DHCP in 3GPP networks.

Not to be dense here, but in the case where the CLAT is not node
resident, how does the
the node get the RFC 1918 address it uses?

> We track broken Android apps at this list (15% don't work:  Skype, Netflix, Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z3j3q

Thanks for the citation.  A quick look at the list shows a number of
the cited applications are no longer
 the current version. Is this being maintained as a living document,
so there are ongoing tests?  If so,
has the introduction of Skype 3, Google plus 3 et al resolved any of these?

> What do you mean 1 IP address?  1 IPv4 address?  They will have pools of address for sure.

The figure/chart between section 8.2 and 8.3 says " Global IPv4
address assigned to IPv4 server";
I took that to mean that PLATs were generally provisioned with a
single address.  With a pool,
the ICE considerations below still apply; it will simply be more
likely that two hosts within a PLAT-served
domain are distinguishable by address as well as address/port.

> We make this restriction because of the case where you and I are on the same ISP.  We both have 10.10.10.1  as our local address. Communication fails.

As long as we are assigned different ports by the PLAT, it does not
fail.  It is suboptimal, but works.

> The rational is that 464XLAT is a best practice for RFC 6144 2.1 network that has IPv4-only apps in it.

If I understand you correctly, it is not simply IPv4-only apps, but
IPv4-only apps which use IPv4-only
referrals.  Is that right?

>> there is no citation given.  I also note that 3GPP specifications currently appear

Just to be clear, you are proposing adding a citation to RFC 6459?

> Current release is not relevant to install base.

The current installed base is not the question I was raising.  If the
problem you are proposing to solve
is limited such that it goes away in 3GPP Release 10, 11, or 12, then
the text should say that in the 3GPP
applicability section.  If an operator/handset manufacturer/app person
targeting a release for
a network can determine whether or not this set of issues will arise
by knowing the relevant 3GPP
release, it would be useful to include that.

> But it does not remove the dependency on IPv4 address that are not available.... public and private addresses are both exhausted, so we use squat space.

You've twice mentioned the squat space used in your network, but the
draft doesn't seem to have any specific
text bearing on this problem.   The most I see is in 7.1, where an
access network simplifies its operations by running v6 only and
trusting an upstream to run the PLAT.  If you think the squat space
use case is important
for understanding the applicability, you may need more text in the draft.

> I will review the wording.  Thanks again for your review.  I look forward to more feedback from you, thanks again for taking the time to work with us and sharing your experience

Thanks again for your quick response.

regards,

Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Mon, 3 Dec 2012 10:13:56 -0800

> i have revision to my previous statements

In-line.

> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron
<snip>
> send packets to each other without something like ICE to force them

There are two cases.  In the first case, the CLAT is node resident.  There, the
CLAT-internal RFC 1918 addresses used by different nodes are
functionally in different
RFC 1918 instances.  That's the same case we get now when different
networks use RFC 1918, just
much smaller.  In the case where two home networks both use RFC 1918,
in other words,
you get the same situation--they must go out to an ICE server to have
p2p communications even
if they are, say, behind the same cable head end.

In the second case, the CLAT is not node resident, but it is not
running an IPv4 routing domain
in the traditional sense; in other words, itt does not offer local
routing among the IPv4 nodes, just
translation to v6.  Here the situations is mildly different from the
two-home-networks-each-using-RFC1918,
but the result from the point of the application is the same--they
must use an ICE server to communicate.

> not work here in the introduction.

Speaking personally, I don't think this is the right choice, because it
makes it appear you are creating a new semantic for RFC 1918 addresses
(a limited case where the usual tools for providing peer to peer connectivity
for them do not work).  If you can't signal that new semantic, the app
has no way of knowing whether the RFC1918 address it has is "full service"
(for whatever that means in the modern NAT and double NAT world) or
"client/server only".  That's making a bad situation worse.

ICE is a complicated bear that no one loves much, but it is currently the
best toolkit we have.  A reference to it and a description of how this
works with
it seems like a better choice to me than creating a new, limited RFC
1918 addressing
semantic.

regards,

Ted Hardie

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 3 Dec 2012 11:36:45 -0800

Hi Ted,

Once again, your feedback is very much appreciated. Comments inline

> I apologize, it appears I did not express this well. I was trying to

I am still a bit unclear on what exactly your concern is, but i will
try to address it below. Sorry for not being able to parse your
meaning, i am bit close to the subject so it hard for me to understand
the gaps you (or any reader) may have in understanding the draft

> but I don't personally see how RFC 6146 justifies or requires it.

The fact that there must be an IPv6-only routing domain is a function
of IPv4 exhaustion (APNIC is already out). Many large access networks
have more customers than address available in the private / shared
allocations. Just to cite 2 examples, AT&T and Verizon Wireless in the
USA each have over 100 million wireless subscribers.

The fact that a  host within an IPv6-only routing domain requires an
IPv4 address to form sockets is attributed to IPv4-only network APIs,
single stack IPv4 hosts,  and the use of IPv4 referals within
otherwise IPv6 capable systems [Skype on Android]

> how a node would know over what networks it would have to use it).

To make a Skype call, Skype must open an socket from an IPv4 address
to an IPv4 address.

464XLAT on the host provides a TUN interface, for example, that the
local host can bind IPv4 sockets to. That TUN interface then performs
RFC 6145.

So, the host can form the IPv4 socket that it previously could not
form.  Packets generated from that interface are immediately
translated from IPv4 to IPv6 and put on the wire with the destination
set for the NAT64 in the first 96 bits and the last 32 for the IPv4
address.

This is all running code.  Here you will find pointers to the Android
implementation for Nexus S, Galaxy Nexus, as well the open source code
that has been accepted by Android Open Source Project:
http://dan.drown.org/android/clat/

This software "just works" on an IPv6-only network such as T-mobile's.
 Before and after tests are readily reproducible that without this
464XLAT software Skype and Netflix do not work (latest version of both
tested within the last 2 weeks) yet with 464XLAT they do work.

> the node get the RFC 1918 address it uses?

Section 8.5 describes the CLAT as a gateway that operates a DHCP server

> has the introduction of Skype 3, Google plus 3 et al resolved any of these?

It is a living document, i have been meaning to do a complete update
of it.  I can likely have that done in a few weeks.

In any event, within the last 2 weeks i have verified that Skype and
Netflix on the latest version from the Android market do not yet work
on IPv6-only + NAT64/DNS64.  These are both on the top 20 list of most
popular apps, so there is no responsible case for moving forward with
IPv6 and letting them break.

Much to my personal disappoint, a Skype engineer (who i assume you
recognize) went on the record yesterday explaining that there is no
demand and therefore no plan to support IPv6 in Skype
http://mailman.nanog.org/pipermail/nanog/2012-December/053918.html

:(

I would rather not need 464XLAT, but these statements from Skype
reflects a reality that it is easier to change the host than it is the
app.

> domain are distinguishable by address as well as address/port.

Yes, you are right.  I can make it more clear that the NAT64 will use
1 or more addresses.

> fail.  It is suboptimal, but works.

Yep, assuming the apps are ICE capable.

> referrals.  Is that right?

Too be clear, the known broken cases that we are trying to fix are
IPv4-only host (ie Windows XP which is at 40% market share IIRC), IPv4
referals (Amazon prime streaming is a well known case), and IPv4-only
network APIs

> Just to be clear, you are proposing adding a citation to RFC 6459?

I can add another citation to RFC 6459 to make this clear

> release, it would be useful to include that.

That is not the case.  The 2 PDP in a 3GPP network issue does go away
in Release 9 and onward, but the problem of demand for IPv4 addresses
exceeding supply does not go away in the case of dual-stack network
connections.  In fact, dual-stack does not improve the problem on
insufficient IPv4 addresses at all.  NAT64 works around the problem of
insufficient IPv4 addresses by translating IPv6 to IPv4... thus the
edge of the network does not require an IPv4 as dearly as it does
today.  The 2 PDP issue is a barrier to offering a dual-stack service
in most of the world today, but in the long run it is  private the
public ipv4 scarcity that is the problem to solve.

464XLAT (incuding NAT64) provides IPv4 independence for network
operators at the edge network.  A few IPv4 addresses can be shared
using statistical multiplexing and all known apps will work.  We
cannot move away from IPv4 unless there is service parity with ipv6,
and that is the goal of 464XLAT.  This goal is demonstrated in running
code.

> for understanding the applicability, you may need more text in the draft.

I'd rather not air my ephemeral dirty laundry in an long lived RFC  :)

The -00 had this text, which was weeded out as too verbose

"Now that both global and private IPv4 addresses are scarce to the
   extent that it is a substantial business risk and limiting growth in
   many areas, the mobile network providers must support IPv6 to solve
   the IP address scarcity issue.  It is not feasible to simply turn on
   additional IPv6 PDP network attachments since that does not solve the
   near-term IPv4 scarcity issues and it increases cost in most cases.
   The most logical path forward is to replace IPv4 with IPv6 and
   replace the common NAT44 with stateful translation [RFC6146] and
   DNS64 [RFC6147].  "

CB

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 3 Dec 2012 11:49:43 -0800

Ted,

> must use an ICE server to communicate.

This is case the where CLAT is just a function of an otherwise normal
home gateway.  I believe normal IP routing and ethernet switching will
occur for the LAN.  The CLAT function only occurs  WAN <-> LAN

> it seems like a better choice to me than creating a new, limited RFC

I agree.  That is why we declared the topology to be hub and spoke in
the draft.  We can add a reference to ICE providing an application
level hub and spoke architecture above the network layer hub and spoke
topology.

does that make sense?

CB

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Dec 2012 10:57:02 -0800

Hi Cameron,

My apologies for the delay in replying.  Some further discussion in-line.

On Mon, Dec 3, 2012 at 11:49 AM, Cameron Byrne <[email-masked]> wrote:

> >> in
> http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2
> >>
If this is the case, then the peer-to-peer functionality is preserved within
the LAN as well.  So you get it in the LAN; you lose it in the WAN (and must
use ICE) and you get the standard behavior in the presence of NAT for
the Internet.  Is that your understanding?

> level hub and spoke architecture above the network layer hub and spoke
Yes,  I think adding the ICE reference and a more nuanced view of where
peer-to-peer will work is a better way forward.

In another message, you made the following comment on why you would
prefer not to include discussion of squat space:

"I'd rather not air my ephemeral dirty laundry in an long lived RFC  :)"

Understood, but the case you're dealing with--a network larger than the
IPv4 address space available in the private address range--is not exactly
dirty laundry, and the lack of new IPv4 allocations is well known.  Those
do help justify this work and might be included.

That said, I am afraid I still don't see this as a BCP, in part because
there is
more than one way to accomplish this.  DPI as a driver for this choice may
be
a 3GPP network-specific thumb on the scales, but I don't think this would
be preferred over encapsulation-based methods in all cases.

As for dirty laundry, I would personally welcome a presentation from you
or your colleagues at the upcoming IETF apps area meeting on what's
breaking here,
as we've been recommending other referral methods and IPv6-native
clients for quite some time.  If we can get people to see exactly how
much hoop jumping is going on in other parts of the stack to get Skype
to work on a perfectly valid v6 network, it would be good.

regards,

Ted

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Dec 2012 11:33:24 -0800

Ted,

> the Internet.  Is that your understanding?

Yes, that is my understanding.

> peer-to-peer will work is a better way forward.

Will do.

> do help justify this work and might be included.

Yes, stating it as:  Many large and fast growing edge networks exceed
the size of the available private IPv4 address space, and thus must
choose between a variety technical comprises within IPv4 or an
immediate transition to IPv6 with an enabling technology such as
464XLAT.

> be preferred over encapsulation-based methods in all cases.

Anything tunnels or DHCP based (including DS-lite and MAP) will not
work in 3GPP, that barriers are too high.  464XLAT navigates the
barriers and is running code with interests from many operators.  But
from a 10,000 foot view, 464XLAT is not a glorious, obvious, or
elegant creation, it is just the tool to get the job done.  It helps
us move IPv6 forward.

That said, the authors of 464XLAT accept whatever the IESG approves.

CB

> or your colleagues at the upcoming IETF apps area meeting on what's breaking
> here,

---

From: SM <[email-masked]>
Date: Sun, 09 Dec 2012 12:12:32 -0800

Hi Cameron,
>to work on a perfectly valid v6 network, it would be good.

Having such a presentation is a good idea in my humble 
opinion.  Skype would be an interesting case study.

Regards,
-sm

---

From: Claudio Allocchio <[email-masked]>
Date: Sun, 9 Dec 2012 22:23:35 +0100 (CET)

On Sun, 9 Dec 2012, SM wrote:

> Having such a presentation is a good idea in my humble opinion.  Skype would 
> be an interesting case study.

... and a big push for reluctant ISPs to enable IPv6 :-) hopfully...

> -sm 

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca