Eleven Fu(Yu | 1 Nov 09:54 2011

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Hi Qiong:

 

   Please see some comments for draft-sunq-v6ops-contents-transition-02 below,

 

Figure 1 is a little misleading. Because NAT64 can only serve the communications initiated by IPv6 side to IPv4 sever. It can’t provide connection service initiated by IPv4 side. However, the figure 1 may give readers some information that it also use NAT64 to serve the connections initiated by IPv4 side to IPv6 sever. So I think some more information may need to be  described in the figure to clarify the IPv4 to IPv6 communitarian scenario.

 

Overall,  I think this solution is meaningful for mid-size and small ICPs to  provide IPv6  access service and is useful to encourage IPv6 traffic.

 

Cheers

 

Yu

 

 

From: v6ops-bounces <at> ietf.org [mailto:v6ops-bounces <at> ietf.org] On Behalf Of Qiong
Sent: Saturday, October 29, 2011 4:38 PM
To: v6ops <at> ietf.org
Subject: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

 

Dear, all,

 

Thanks for your feedback from IETF 81th. We have updated a new version of "Rapid Transition of IPv4 contents to be IPv6-accessible". We have deployed several models for the transition of IPv4 services to IPv6 in our commercial network, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet while preserving the continuity of IPv4 service delivery. We would like to share our experiments and considerations. Anyway, content transition is very important in the whole IPv6 transition process.

 

 

Your comments will be very much appreciated.  Thanks in advance!

 

Best wishes

 

Qiong

 

---------- Forwarded message ----------
From: sunqiong <sunqiong <at> ctbri.com.cn>
Date: Sat, Oct 29, 2011 at 4:20 PM
Subject: Fw: New Version Notification fordraft-sunq-v6ops-contents-transition-02.txt
A new version of I-D, draft-sunq-v6ops-contents-transition-02.txt has been successfully submitted by Qiong Sun and posted to the IETF repository.

 

Filename:  draft-sunq-v6ops-contents-transition

Revision:  02

Title:  Rapid Transition of IPv4 contents to be IPv6-accessible

Creation date:  2011-10-29

WG ID:  Individual Submission

Number of pages: 14

Abstract:

   This document describes several deployment models for the transition

   of IPv4 services to IPv6, aiming at rapidly increasing the amount of

   IPv6 accessible contents for users from IPv6 Internet while

   preserving the continuity of IPv4 service delivery.

                                                                                  

The IETF Secretariat

 

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tore Anderson | 1 Nov 10:10 2011

Re: new draft: draft-carpenter-v6ops-icp-guidance

* Brian E Carpenter

> That is a very different deployment model than
> draft-carpenter-v6ops-icp-guidance advocates. I can understand that
> there might be unusual circumstances in which it would be chosen, but
> it is so much simpler to dual-stack all servers.

In a purely technical sense, you might be right. However, I've come to
realize that dual-stack is not really a viable transition approach for
us, due to organizational and human considerations. I think the draft is
intended exactly for organizations such as ours btw, as we're a
small/medium-sized ICP.

We have a team of people that works on the network infrastructure (of
which I'm part), and several teams with sysadmins that operate the
customers' servers, operating systems, and the applications running on
them. While my colleagues and I are happy to promote IPv6 by always
assigning an IPv6 prefix to all LANs that are requested by the server
guys, their priorities are very different - they don't want to get
involved more networking than absolutely necessary. So if I give them
two IP stacks to work with, they'll choose one and leave the other one
unused, and not surprisingly, the one they choose to work with is going
to be the most familiar one - IPv4.

I can understand it, too - dual stack is in a sense dual work and dual
complexity. They'd need to configure ACLs twice, monitor everything
twice, accept lots of new failure scenarios and so on. It's real
operational overhead, and nobody really wants that.

If there is an explicit demand from the customer to have IPv6
availability, that changes things somewhat - but usually not more than
causing a dual-stacking of the public internet-facing frontends. Most
servers remain IPv4-only, while only the load balancers/web
servers/whatever gets an additional IPv6 address that can be published
in DNS. In any case, customer requests for IPv6 are few and far between,
and to this date no customer has ever asked us for a dual-stacking of
all of his servers.

After all, dual-stack as a transition mechanism has gained approx. zero
momentum in the decade it's been the recommended IPv6 transition
mechanism. I don't see any reason why that would change any time soon.

I'm instead pursuing a path where I'll give the sysadmins single-stack
IPv6 to work with, and handle IPv4 connectivity as a translation
function in the core network (e.g. using SIIT). We'll see how that works
out in the end, but it has some advantages over dual-stack, in my
opinion: First, it forces the sysadmins to actually make use of IPv6.
Second, it doesn't require them to deal with more than 1 IP protocol.
Third, and perhaps most importantly, it helps a lot with IPv4 depletion.

Best regards,
--

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Brian E Carpenter | 1 Nov 21:16 2011
Picon

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

I'm not seeing why this is a better solution for a small/medium ICP
than just moving to a dual stack. That is much easier for a small
network than for a big one.

Regards
   Brian

On 2011-11-01 21:54, Eleven Fu(Yu) wrote:
> Hi Qiong:
> 
>    Please see some comments for draft-sunq-v6ops-contents-transition-02 below,
> 
> Figure 1 is a little misleading. Because NAT64 can only serve the communications initiated by IPv6 side to
IPv4 sever. It can’t provide connection service initiated by IPv4 side. However, the figure 1 may give
readers some information that it also use NAT64 to serve the connections initiated by IPv4 side to IPv6
sever. So I think some more information may need to be  described in the figure to clarify the IPv4 to IPv6
communitarian scenario.
> 
> Overall,  I think this solution is meaningful for mid-size and small ICPs to  provide IPv6  access service
and is useful to encourage IPv6 traffic.
> 
> Cheers
> 
> Yu
> 
> 
> From: v6ops-bounces <at> ietf.org<mailto:v6ops-bounces <at> ietf.org>
[mailto:v6ops-bounces <at> ietf.org]<mailto:[mailto:v6ops-bounces <at> ietf.org]> On Behalf Of Qiong
> Sent: Saturday, October 29, 2011 4:38 PM
> To: v6ops <at> ietf.org<mailto:v6ops <at> ietf.org>
> Subject: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt
> 
> Dear, all,
> 
> Thanks for your feedback from IETF 81th. We have updated a new version of "Rapid Transition of IPv4
contents to be IPv6-accessible". We have deployed several models for the transition of IPv4 services to
IPv6 in our commercial network, aiming at rapidly increasing the amount of IPv6 accessible contents for
users from IPv6 Internet while preserving the continuity of IPv4 service delivery. We would like to share
our experiments and considerations. Anyway, content transition is very important in the whole IPv6
transition process.
> 
> You can find it through: http://tools.ietf.org/id/draft-sunq-v6ops-contents-transition-02.txt
> 
> Your comments will be very much appreciated.  Thanks in advance!
> 
> Best wishes
> 
> Qiong
> 
> ---------- Forwarded message ----------
> From: sunqiong <sunqiong <at> ctbri.com.cn<mailto:sunqiong <at> ctbri.com.cn>>
> Date: Sat, Oct 29, 2011 at 4:20 PM
> Subject: Fw: New Version Notification fordraft-sunq-v6ops-contents-transition-02.txt
> A new version of I-D, draft-sunq-v6ops-contents-transition-02.txt has been successfully submitted
by Qiong Sun and posted to the IETF repository.
> 
> Filename:  draft-sunq-v6ops-contents-transition
> Revision:  02
> Title:  Rapid Transition of IPv4 contents to be IPv6-accessible
> Creation date:  2011-10-29
> WG ID:  Individual Submission
> Number of pages: 14
> Abstract:
>    This document describes several deployment models for the transition
>    of IPv4 services to IPv6, aiming at rapidly increasing the amount of
>    IPv6 accessible contents for users from IPv6 Internet while
>    preserving the continuity of IPv4 service delivery.
> 
> The IETF Secretariat
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops <at> ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
Brian E Carpenter | 1 Nov 21:27 2011
Picon

Re: new draft: draft-carpenter-v6ops-icp-guidance

Grumble. I don't like that conclusion, because it's clear that
the desired end point is native v6 and I don't see how your
approach gets us there.

OK, if the draft becomes a WG draft, I can see that we would
need to add the draft-sunq-v6ops-contents-transition model
to the outside-in scenario, as an alternative to the dual
stack proxy. However, although the proxy may be a bit slower,
it strikes me as a much cleaner solution than NAT64. And
of course it's off-the-shelf running code.

Regards
   Brian

On 2011-11-01 22:10, Tore Anderson wrote:
> * Brian E Carpenter
> 
>> That is a very different deployment model than
>> draft-carpenter-v6ops-icp-guidance advocates. I can understand that
>> there might be unusual circumstances in which it would be chosen, but
>> it is so much simpler to dual-stack all servers.
> 
> In a purely technical sense, you might be right. However, I've come to
> realize that dual-stack is not really a viable transition approach for
> us, due to organizational and human considerations. I think the draft is
> intended exactly for organizations such as ours btw, as we're a
> small/medium-sized ICP.
> 
> We have a team of people that works on the network infrastructure (of
> which I'm part), and several teams with sysadmins that operate the
> customers' servers, operating systems, and the applications running on
> them. While my colleagues and I are happy to promote IPv6 by always
> assigning an IPv6 prefix to all LANs that are requested by the server
> guys, their priorities are very different - they don't want to get
> involved more networking than absolutely necessary. So if I give them
> two IP stacks to work with, they'll choose one and leave the other one
> unused, and not surprisingly, the one they choose to work with is going
> to be the most familiar one - IPv4.
> 
> I can understand it, too - dual stack is in a sense dual work and dual
> complexity. They'd need to configure ACLs twice, monitor everything
> twice, accept lots of new failure scenarios and so on. It's real
> operational overhead, and nobody really wants that.
> 
> If there is an explicit demand from the customer to have IPv6
> availability, that changes things somewhat - but usually not more than
> causing a dual-stacking of the public internet-facing frontends. Most
> servers remain IPv4-only, while only the load balancers/web
> servers/whatever gets an additional IPv6 address that can be published
> in DNS. In any case, customer requests for IPv6 are few and far between,
> and to this date no customer has ever asked us for a dual-stacking of
> all of his servers.
> 
> After all, dual-stack as a transition mechanism has gained approx. zero
> momentum in the decade it's been the recommended IPv6 transition
> mechanism. I don't see any reason why that would change any time soon.
> 
> I'm instead pursuing a path where I'll give the sysadmins single-stack
> IPv6 to work with, and handle IPv4 connectivity as a translation
> function in the core network (e.g. using SIIT). We'll see how that works
> out in the end, but it has some advantages over dual-stack, in my
> opinion: First, it forces the sysadmins to actually make use of IPv6.
> Second, it doesn't require them to deal with more than 1 IP protocol.
> Third, and perhaps most importantly, it helps a lot with IPv4 depletion.
> 
> Best regards,
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Qiong | 2 Nov 06:04 2011
Picon

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Hi Yu,


Thanks for your comments. Please see inline :)

On Tue, Nov 1, 2011 at 4:54 PM, Eleven Fu(Yu) <eleven.fuyu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:

Hi Qiong:

 

   Please see some comments for draft-sunq-v6ops-contents-transition-02 below,

 

Figure 1 is a little misleading. Because NAT64 can only serve the communications initiated by IPv6 side to IPv4 sever. It can’t provide connection service initiated by IPv4 side. However, the figure 1 may give readers some information that it also use NAT64 to serve the connections initiated by IPv4 side to IPv6 sever. So I think some more information may need to be  described in the figure to clarify the IPv4 to IPv6 communitarian scenario.


Sorry for misleading, and we would clarify it in the next version. Our deployment model includes both stateful NAT64 and stateless NAT64(IVI), in which stateful NAT64 is for scenario initiated by IPv6 side to IPv4 server, while stateless NAT64(IVI) is for IPv4 initiated client to IPv6 server. 

 

Overall,  I think this solution is meaningful for mid-size and small ICPs to  provide IPv6  access service and is useful to encourage IPv6 traffic.

 

Thanks. Our basic idea is to encourage IPv6 traffic and enrich IPv6 contents ASAP. Actually, we have discussed with many ICPs and their situations are quite complicated. Some of them even do not realize what is IPv6, but just keep asking us whether we have IPv6 customers or not.
We believe that the amount IPv6 traffic and IPv6-reachable contents is a key point to the development of IPv6. After so many years of IPv6 research, our whole community really need the confidence to move forward, and maybe IPv6 traffic is most convincing. Although it is a only initial step kind of not so clean, but it does help enriching IPv6 content for a great many ICPs. What's why we would like to offer transition service to ICPs at low cost.

Best wishes

Qiong   
 

Cheers

 

Yu

 

 

From: v6ops-bounces <at> ietf.org [mailto:v6ops-bounces-EgrivxUAwEY@public.gmane.org] On Behalf Of Qiong
Sent: Saturday, October 29, 2011 4:38 PM
To: v6ops <at> ietf.org
Subject: [v6ops] Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

 

Dear, all,

 

Thanks for your feedback from IETF 81th. We have updated a new version of "Rapid Transition of IPv4 contents to be IPv6-accessible". We have deployed several models for the transition of IPv4 services to IPv6 in our commercial network, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet while preserving the continuity of IPv4 service delivery. We would like to share our experiments and considerations. Anyway, content transition is very important in the whole IPv6 transition process.

 

 

Your comments will be very much appreciated.  Thanks in advance!

 

Best wishes

 

Qiong

 

---------- Forwarded message ----------
From: sunqiong <sunqiong-FImTtDR9191v1O+Z8WTAqQ@public.gmane.org>
Date: Sat, Oct 29, 2011 at 4:20 PM
Subject: Fw: New Version Notification fordraft-sunq-v6ops-contents-transition-02.txt
A new version of I-D, draft-sunq-v6ops-contents-transition-02.txt has been successfully submitted by Qiong Sun and posted to the IETF repository.

 

Filename:  draft-sunq-v6ops-contents-transition

Revision:  02

Title:  Rapid Transition of IPv4 contents to be IPv6-accessible

Creation date:  2011-10-29

WG ID:  Individual Submission

Number of pages: 14

Abstract:

   This document describes several deployment models for the transition

   of IPv4 services to IPv6, aiming at rapidly increasing the amount of

   IPv6 accessible contents for users from IPv6 Internet while

   preserving the continuity of IPv4 service delivery.

                                                                                  

The IETF Secretariat

 


_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Mark Andrews | 2 Nov 08:13 2011

Re: new draft: draft-carpenter-v6ops-icp-guidance


In message <4EAFB76D.7070208@...>, Tore Anderson writes:
> * Brian E Carpenter
> 
> > That is a very different deployment model than
> > draft-carpenter-v6ops-icp-guidance advocates. I can understand that
> > there might be unusual circumstances in which it would be chosen, but
> > it is so much simpler to dual-stack all servers.
> 
> In a purely technical sense, you might be right. However, I've come to
> realize that dual-stack is not really a viable transition approach for
> us, due to organizational and human considerations. I think the draft is
> intended exactly for organizations such as ours btw, as we're a
> small/medium-sized ICP.
> 
> We have a team of people that works on the network infrastructure (of
> which I'm part), and several teams with sysadmins that operate the
> customers' servers, operating systems, and the applications running on
> them. While my colleagues and I are happy to promote IPv6 by always
> assigning an IPv6 prefix to all LANs that are requested by the server
> guys, their priorities are very different - they don't want to get
> involved more networking than absolutely necessary. So if I give them
> two IP stacks to work with, they'll choose one and leave the other one
> unused, and not surprisingly, the one they choose to work with is going
> to be the most familiar one - IPv4.
> 
> I can understand it, too - dual stack is in a sense dual work and dual
> complexity. They'd need to configure ACLs twice, monitor everything
> twice, accept lots of new failure scenarios and so on. It's real
> operational overhead, and nobody really wants that.

Our ops people would say you are exagerating the costs.  They have
7+ years of dual stack experience.  It's not zero but is close to
that.

Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@...
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Qiong | 2 Nov 09:23 2011
Picon

Re: Fwd: New Version Notification for draft-sunq-v6ops-contents-transition-02.txt

Hi Brian,


Thanks for your comments.

I agree that dual-stack is a very straightforward way to IPv6 and should be recommended in general. But frankly, I think the situation we are facing with seems much more complicated, sometimes beyond technical issues. Most ICPs are still lacking of motivation to upgrade, just waiting for v6 users. And in the same way, operators are also hesitating to deploy v6 when there are very few existing v6 contents. This chicken and egg thing is still ongoing, even we are running out IPv4 address.

After all, dual stack is what we have discussing for 10 years. But up to now, how many ICPs have upgraded to IPv6 in dual-stack directly? I really think we need to re-think it again, from both technical aspect and the industry/or market aspect. And the first step is rather important to give us confidence to move forward. That's why we recommend single-stack (either v4 or v6) transition in the current phase. Then, for the conservative ones, the IPv4 services can be still offered natively, and the IPv6 services can be offered by the stateful NAT64; while for progressive ones and newly comers, the stateless IVI can be employed to offer native IPv6 services reachable via IPv4. And we hope it would help enrich IPv6 content asap. Then how do you think ?

Thanks

Qiong


On Wed, Nov 2, 2011 at 4:16 AM, Brian E Carpenter <brian.e.carpenter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I'm not seeing why this is a better solution for a small/medium ICP
than just moving to a dual stack. That is much easier for a small
network than for a big one.

Regards
  Brian

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tore Anderson | 2 Nov 10:05 2011

Re: new draft: draft-carpenter-v6ops-icp-guidance

* Brian E Carpenter

> Grumble. I don't like that conclusion, because it's clear that
> the desired end point is native v6 and I don't see how your
> approach gets us there.

Native IPv6 on all servers and used by all applications running on those
servers doesn't get us to native IPv6? Huh? :-)

--

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Tore Anderson | 2 Nov 10:22 2011

Re: new draft: draft-carpenter-v6ops-icp-guidance

* Mark Andrews

> In message <4EAFB76D.7070208@...>, Tore
Anderson writes:
>>
>> In a purely technical sense, you might be right. However, I've come to
>> realize that dual-stack is not really a viable transition approach for
>> us, due to organizational and human considerations. I think the draft is
>> intended exactly for organizations such as ours btw, as we're a
>> small/medium-sized ICP.
>>
>> We have a team of people that works on the network infrastructure (of
>> which I'm part), and several teams with sysadmins that operate the
>> customers' servers, operating systems, and the applications running on
>> them. While my colleagues and I are happy to promote IPv6 by always
>> assigning an IPv6 prefix to all LANs that are requested by the server
>> guys, their priorities are very different - they don't want to get
>> involved more networking than absolutely necessary. So if I give them
>> two IP stacks to work with, they'll choose one and leave the other one
>> unused, and not surprisingly, the one they choose to work with is going
>> to be the most familiar one - IPv4.
>>
>> I can understand it, too - dual stack is in a sense dual work and dual
>> complexity. They'd need to configure ACLs twice, monitor everything
>> twice, accept lots of new failure scenarios and so on. It's real
>> operational overhead, and nobody really wants that.
> 
> Our ops people would say you are exagerating the costs.

Considering I didn't mention costs at all, I'm not sure how you came to
that conclusion. I don't believe that dual stack mean you have to double
your operations budget. The added technical complexity is the main
problem for us, not costs.

Not even an hour after I sent my previous e-mail yesterday, a colleague
came over to me asking if I could look into why some accounting cron
jobs had stopped working since last month. Turns out the problem was
that a server had been recently dual-stacked, which caused a download
job from another server (which had been dual-stacked for a long time) to
fail, because the ACLs that allowed the download to happen over IPv4
wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately
not critical at all, but it's an example of a failure scenario you are
open to only when running dual-stack.

Best regards,
--

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Mark Andrews | 2 Nov 12:11 2011

Re: new draft: draft-carpenter-v6ops-icp-guidance


In message <4EB10BDA.3060202@...>, Tore Anderson writes:
> * Mark Andrews
> 
> > In message <4EAFB76D.7070208@...>, Tore
Anderson writes:
> >>
> >> In a purely technical sense, you might be right. However, I've come to
> >> realize that dual-stack is not really a viable transition approach for
> >> us, due to organizational and human considerations. I think the draft is
> >> intended exactly for organizations such as ours btw, as we're a
> >> small/medium-sized ICP.
> >>
> >> We have a team of people that works on the network infrastructure (of
> >> which I'm part), and several teams with sysadmins that operate the
> >> customers' servers, operating systems, and the applications running on
> >> them. While my colleagues and I are happy to promote IPv6 by always
> >> assigning an IPv6 prefix to all LANs that are requested by the server
> >> guys, their priorities are very different - they don't want to get
> >> involved more networking than absolutely necessary. So if I give them
> >> two IP stacks to work with, they'll choose one and leave the other one
> >> unused, and not surprisingly, the one they choose to work with is going
> >> to be the most familiar one - IPv4.
> >>
> >> I can understand it, too - dual stack is in a sense dual work and dual
> >> complexity. They'd need to configure ACLs twice, monitor everything
> >> twice, accept lots of new failure scenarios and so on. It's real
> >> operational overhead, and nobody really wants that.
> > 
> > Our ops people would say you are exagerating the costs.
> 
> Considering I didn't mention costs at all, I'm not sure how you came to
> that conclusion. I don't believe that dual stack mean you have to double
> your operations budget. The added technical complexity is the main
> problem for us, not costs.
> 
> Not even an hour after I sent my previous e-mail yesterday, a colleague
> came over to me asking if I could look into why some accounting cron
> jobs had stopped working since last month. Turns out the problem was
> that a server had been recently dual-stacked, which caused a download
> job from another server (which had been dual-stacked for a long time) to
> fail, because the ACLs that allowed the download to happen over IPv4
> wasn't properly duplicated in IPv6. Easy enough to fix, and fortunately
> not critical at all, but it's an example of a failure scenario you are
> open to only when running dual-stack.

I would suggest that your tools are not RFC 1123 compliant as they
didn't cope with a multi-homed servers.  This failure could have
happened with IPv4 only.  It's only been been 22 years since support
for multi-homed servers was recommended.

> Best regards,
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@...
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops


Gmane