Hi, Fred:

 

1) Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational problems does the proposal address in real life networks?

// When we made series trials in the real life network in the last two years, we found there are many problems arose in the practice and Native dual stack sounds like a suitable method for our network migration. The reasons why other kinds of transition technologies are not very suitable for our network, such as 4over6, 6over4, are briefly listed in the Introduction in this draft and detailed explained in “draft-yang-v6ops-FAST6-tool-selection-01”.

   However, in order to make a quick response to address exhaustion, native dual stack has to cooperate with address sharing technology. We made a trial in real life network using “native dual stack+ carrier grade NAT” and  we find there is mixed routing problem in the network. In the initial stage, the CGNs have to be distributed in the Network Edge (such as BNG) since the large amount of IPv4 traffic (according to the prediction data for our network ). In this case, private IPv4 routing and public IPv4 routing will coexist in the network.
   The proposal, FAST6 addresses this problems described above in real life network through establishing a private-in-public IPv4 tunnel between FTS and FTN to isolate the routings in network.In practice , the tunnel between FTS and FTN is usually a tunnel between BNG and CR. So it can solve the mixed routing problem in network.

2) Where does this draft or presentation fits into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) of the charter is preferable.

We list the provisions in chart this draft fit into as below:

(1)   The IPv6 Operations Working Group (v6ops) develops guidelines for the operation of a shared IPv4/IPv6 Internet.

(2)  The main focus of the v6ops WG is to look at the immediate deployment issues. FAST6 is designed for very initial step of deployment.

(3)  Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. FAST6 have describe the operation problem we meet in practice and give the solution.

3) Who is this draft's audience?

 Although FAST6 is designed with our own network experience, it is suitable for many other operators. The audiences are network operators whose public address space is very limited and will be exhausted in very short recently which means they have no time to reform their network to native IPv6 in specified short time. They may have to use carrier grade NAT to deal the emergent situation, FAST6 can info them some operation problems in real life network and the solution.

4) Have any operators expressed interest in this draft or its problem space, either via review or other discussion?
   China Telecom express strong interest in this draft. We are eagerly hoping the other operators’ response in the draft.
5) Is this draft pursuing discussion in any other WGs? If so, please list them here, along with rationale for the interaction with multiple WGs in parallel. 
   We only post it in v6ops WG and didn’t have discussion in other WGs yet.

6) Is any protocol work being recommended in the draft?
    There is no change of any protocol in this draft.

===== 回复前原始邮件 =====


发件人：fred <at> cisco.com
日期：2012/03/31 20:45:01
收件人：draft-yang-v6ops-fast6 <at> tools.ietf.org
抄送：v6ops-chairs <at> tools.ietf.org
主题：Some questions on draft-yang-v6ops-fast6

Let me ask some questions. This is not intended to put you off or offend, but to help the chairs in understanding where the draft fits in the big scheme of things.

1) Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational problems does the proposal address in real life networks?

2) Where does this draft or presentation fits into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) of the charter is preferable.

3) Who is this draft's audience?

4) Have any operators expressed interest in this draft or its problem space, either via review or other discussion?

5) Is this draft pursuing discussion in any other WGs? If so, please list them here, along with rationale for the interaction with multiple WGs in parallel.

6) Is any protocol work being recommended in the draft?

the criteria the WG asked me to apply for new work or presentation slots are:
- recent or recently updated draft
- within charter
- results in constructive discussion on the mailing list

I need for you to provoke discussion on the list. You may respond to my opening email to do so if it's helpful.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Hi, Fred:

 

  I forget to mention, for your fisrt question "Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational", we will verify our second version with more intuitive description. 

===== 回复前原始邮件 =====


发件人：fred <at> cisco.com
日期：2012/03/31 20:45:01
收件人：draft-yang-v6ops-fast6 <at> tools.ietf.org
抄送：v6ops-chairs <at> tools.ietf.org
主题：Some questions on draft-yang-v6ops-fast6

Let me ask some questions. This is not intended to put you off or offend, but to help the chairs in understanding where the draft fits in the big scheme of things.

1) Please provide a succinct problem statement for your draft. What problem/issue is this draft discussing? What operational problems does the proposal address in real life networks?

2) Where does this draft or presentation fits into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing specific a section(s) of the charter is preferable.

3) Who is this draft's audience?

4) Have any operators expressed interest in this draft or its problem space, either via review or other discussion?

5) Is this draft pursuing discussion in any other WGs? If so, please list them here, along with rationale for the interaction with multiple WGs in parallel.

6) Is any protocol work being recommended in the draft?

the criteria the WG asked me to apply for new work or presentation slots are:
- recent or recently updated draft
- within charter
- results in constructive discussion on the mailing list

I need for you to provoke discussion on the list. You may respond to my opening email to do so if it's helpful.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

I've stated previously on this list that I fundamentally disagree with this draft. After reviewing the latest text, I continue to hold this viewpoint.

For the mechanism in the draft to work, untraceable packets have to be allowed across an AS boundary (section 4). It therefore negates the good work of BCP84 RFC3704 in mitigating DDoS and other untraceable attacks from spoofed addresses.

This untraceable source address range will be abused.

So IHMO, either network operators will filter all traffic from the newly assigned shared range, and the draft will not achieve its stated goal, or network operators will not filter this traffic, and thus expose themselves to being a transit for a DDoS attack that they cannot prove was not sourced within their AS. Either way, it will lead to an undesirable operational situation (draft not working, or operator exposed to untraceable abuse).

The authors have spent considerable effort on defining mitigation measures, such as rate limiting at source, but the fact of the matter is that bad guys don't obey RFC's, and so the mitigation measures defined in the draft will not adequately protect against abuse.

There are also alternatives available to assigning the proposed address range: using RFC1918 addresses within an AS, assigning a small range from a provider's existing IPv4 allocation, or even sharing assigned IPv4 PI address space across multiple providers (with one network provider taking the lead in coordinating help desk responses to queries upon abuse.) These alternatives are in no way ideal, but they will work, and are traceable back to a source/ network abuse help desk.

IPv4 addresses may have run out, but we shouldn't break existing implementations and operations.

regards,
RayH

Fred Baker wrote:

This is to initiate a two week working group last call of draft-ietf-v6ops-ivi-icmp-address. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

On Apr 3, 2012 12:32 AM, "Rémi Després" <despres.remi-QFKgK+z4sOrR7s880joybQ@public.gmane.org> wrote:
>
> Hi, Cameron,
>
> Sorry for the late answer (was on second priority for a few days).
>
> Le 2012-03-27 à 12:38, Cameron Byrne a écrit :
>
> > hi,
> >
> > On Tue, Mar 27, 2012 at 1:17 AM, Rémi Després <despres.remi-QFKgK+z4sOrR7s880joybQ@public.gmane.org> wrote:
> >>
> >> Le 2012-03-27 à 04:34, Fred Baker a écrit :
> ...
> >>>
> >>> The objections raised in the working group come down to:
> >>>   - the authors of said other documents would like to have a conversation with the 464XLAT folks
> >>>   - What's this about a prefix::/96?
> >>>   - What's this about a proxy service?
> >>
> >> There was also a point about NAT44 in CLAT nodes or not (point discussed on the ML)
> >>
> >
> > The NAT44 text on the CLAT has been integrated here:
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5
> >
> > "Alternatively, the CLAT may do NAT44
> >   such that all private IPv4 sourced LAN packets appears from one
> >   private IPv4 address which is statelessly translated to one IPv6
> >   address that the CLAT will own as a host IPv6 address from an IPv6
> >   /64 interface."
>
> Thanks, good enough for me.
>
> >> May I add that the relationship between 464XLAT and BIH (RFC6535) would also be worth clarifying. (I see high similarity: v4 only applications communicating in IPv6).
> >>
> >
> > BIH explicitly does not allow double translation, it's scope is
> > explicitly limited to the case of using IPv4 applications to IPv6-only
> > servers.  I objected to this limitation in BEHAVE.  But, it is what it
> > is.
>
> BIH "recommends" to avoid double translation.
> This AFAIK permits it if good reasons are found.
>

Yes, it is an all capital letter recommendation.  As you likely well know, ipv6 transition is an ecosystem transition and recommendations like the one in BIH become a lightening rod for confusion. We can leave it at that.

> > That said, 464XLAT authors have found rfc6145 to be the best fit for
> > IPv4->IPv6 translation, including support for the function in a more
> > generic node such as a router (home gateway CPE, mobile phone as a
> > host, mobile phone as a wifi router, ...)
>
> BIH does include RFC6145 translation.
>

If I read section 2.3 correctly of bih, it requires all sessions be created by enr.

In the network implementation of bih, bih cannot support ipv4 communication that does not start with DNS because DNS triggers the enr. So, bih on a router cannot facilitate for a client of  the router a Skype call  since Skype signals ipv4 literals.
The bih router (which does not exist) cannot create the enr triggered session mappings with capturing DNS first.

> > where BIH is constrained to
> > a host only style implementation that relies on host level API
> > modification and interaction
>
> A host can also be also a router, in particular if it includes a NAT44.
> I see nothing that prevents using it in this case.
>

I don't believe bih had this use case in scope. The diagrams and text in bih make reference to a host, not a host / router.

Trust me, if bih worked as you suggest, my life would be much easier. If bih officially worked with nat64 and did not require the enr mapper so that it supported ipv4 literals in network mode, that would be great. In fact, I pushed for both when bih was a draft in behave.

> >>>   - What's this about normative language?
> >>
> >>>   - How does it fit the the mdt-softwire-map specifications, which
> >>>     appear to have a growing consensus behind them in softwire?
> >>
> >> The point made during the meeting was about the work in Softwire in general. replacing this point by a reference to the mdt draft is a biased interpretation.
> >> In Softwire, a choice between MAP and Unified is scheduled for Friday morning. As chair of v6ops, it would be better to avoid making a Softwire choice before the scheduled debate has taken place (IMHO).
> >> Thanks.
> >>
> >
> > I hope my previous emails have made the case for a stateful solution
> > clear and useful
>
> I thought we had both understood that there are needs for stateful AND ALSO for stateless, in particular where mesh topologies are desirable. This depends on provider cases.
> End of this issue for me.
>

We do agree.

> > As it stands, there is no workable stateful (more IPv4 address
> > efficient / intensive) IETF method of operating in an IPv6-only access
> > network.
>
> > NAT64/DNS64 is not workable, since 15% of applications on
> > mobile (something similar for desktop) fail to work without some way
> > to deal with IPv4 specific sockets and IPv4 literals.
>
> Can we agree to only say that NAT64/DNS64 is NOT SUFFICIENT? (Without saying that it doesn't do work for what it has been designed for).
>

We agree on this too.

Cb
> Regards,
> RD
>
> >
> > CB
> >> regards,
> >> RD
> >>
> >>
> >>>
> >>> Before you continue reading this note, please stop and read these two sections:
> >>>   http://tools.ietf.org/html/rfc2026#section-4.2.2
> >>>   http://tools.ietf.org/html/rfc2026#section-5
> >>>
> >>> From my perspective, and from reading those definitions, an Informational Document is a white paper, while a BCP is something that a significant and relevant part of the Internet COmmunity agrees to, and
> >>>
> >>> ...since the Internet itself is composed of networks operated by a great
> >>>  variety of organizations, with diverse goals and rules, good user
> >>>  service requires that the operators and administrators of the
> >>>  Internet follow some common guidelines for policies and operations.
> >>>
> >>> In other words, operational service models, while not strictly speaking "protocols", can be described in a BCP *standard* as "how to implement a certain service". This is in no sense "the best" or "only way to deploy RFCs 6145/6146", but it might be "the best way to deploy the CLAT service". v6ops is authorized, by charter, to write informational and BCP documents.
> >>>
> >>> And since a BCP describes the set of things that one MUST or SHOULD do in deploying such a service, RFC 2119 language regarding that specific service may be acceptable in a BCP describing that service.
> >>>
> >>>
> >>> With that preparatory reasoning, it seems to me that we need to separate the contentious parts of the specification so that uncontentious parts can go forward, and other parts can be discussed - whether in this working group or another one.
> >>>
> >>>
> >>> Given the points of contention, it seems that the separation needs to be among three documents.
> >>>
> >>> The first is a specification - a BCP - for the CLAT service. It refers to RFCs 6052/6144/6145/6146/6147, and describes how translation is used in this context using normative language. It does not refer to a prefix::/96; it refers to RFC 6052. My understanding is that several people have said that this specification is interesting and useful.
> >>>
> >>> The second is a separate specification for the proxy service, which is contentious. Being separated, it can be discussed and beaten to death as needed. The first specification says that the CLAT service MAY implement this proxy service. I'm not sure whether that is BCP or Informational; we can discuss that in the context of the rest of the discussion of the proxy service.
> >>>
> >>> The third is a report on the trial deployment of the CLAT service by the various companies in question. This is an informational document.
> >>>
> >>> Am I making sense? Would this be an acceptable way forward?
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops-EgrivxUAwEY@public.gmane.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
>

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops