Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

[Rémi Després <[e-mail]>]

Cameron,

Thanks for the additional information below.
More comments in line.

Le 2012-02-20 à 16:32, Cameron Byrne a écrit :
> On Mon, Feb 20, 2012 at 1:52 AM, Rémi Després <[e-mail]> wrote:
...
>> In any case, my question isn't about understanding the specification (clear enough IMHO for this level of discussion). It reflects interest for a more complete draft describing the trial configuration, with its configuration parameters. (The specification describes a number of options: with or without DNS64; possibility that an "access networks that does not allow for a dedicated translation prefix"; CLATs that may get /64s via DHCPv6 or by other means; inclusion fragment headers possibly systematic but optional; possibility for some CLATs to get longer than /64 IPv6 prefixes).
> 
> Glad to clarify this here.  My trial required no change to the
> IPv6-only DNS64/NAT64 network beta service that i have offered to by
> customers for close to 2 years now.  Adding 464XLAT was purely a CPE
> function layered onto that existing network "as is".
> 
> 1. Yes, we use DNS64

OK. 
Could you clarify then what justifies that "It does not require DNS64".

> 2. A dedicated translation prefix was not used.  Since my 3GPP Release
> 7 network does not support DHCP at all, the address is pushed to the
> UE as part of PDP setup in the PCO IE.

Why, then, say "In the best case, the CLAT will have a dedicated /64"  

>  This is how all IPv4 and IPv6
> addresses are assigned to UEs in my network.

Is this with a standard format (if yes, a reference would make it clear).

> 3.  The UE, which is also the CLAT, received a single /64 of IPv6 from
> the network

OK.

> and no IPv4.

(Already understood, otherwise nothing new would be needed)


>  This is the only address scheme that was
> used or can be used in my network
> 
> 4.  There was no change to the RFC 6146/6145 behavior, fragment
> headers were included.

Then why to add a section which describes two variants.
Besides, I didn't understand this sentence "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 host does not set the DF bit*" (asterisks added). 
> 
> 5.  Pref64/n was discovered using draft-ietf-behave-nat64-discovery-heuristic

OK.


>> I just say that a real "trial deployment report" would be nice to have, but of course no obligation.
>> 
> 
> I am attempting to operate as transparently as possible.  

> Please feel
> free to query me further.

There is some of this of this above, thanks.

...
>> The draft does include SHOULDs and MAYs that belong to standardization vocabulary, e.g.:
>> "In cases where the access network does not allow for a dedicated translation prefix, the CLAT SHOULD take ownership of the lowest /96 from an attached interface's /64 to source and receive translation traffic. Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP so that no other nodes on the /64 may use the lowest /96."
>> 
> 
> Correct.  The authors, including myself, are not as experience as you,

I am not as much experienced in IETF procedures as you seem to believe.
Like yourself, I try to understand and apply BCPs.

> but i believe informational I-D may use this language.
> 
> Just looking, RFC6092 is informational and uses this language.

Personally, I find it confusing in RFC6092, but this is another subject.

> Also,
> we are open to changing the document type to BCP or Standard Track if
> that is a better fit.  It has been recommended on list that this draft
> go standards track.  So, i believe there is an open discussion here.
> We can adjust as the WG sees fit.  Right now, i feel most comfortable
> with informational.  I don't think experimental is helpful to network
> operators that trying to solve a near term problem with "no new
> technology".

My point is that it includes some behavior specification (464XLAT compliance is more than just compliance with RFCs it refers to).

...

> 
>>>    RFC6145 is not MAP or
>>> 4RD.
>> 
>> Why you say this is unclear. AFAIK nobody ever suggested that.
>> 
> 
> I keep getting the feeling like 464XLAT should be abandoned and the
> use cases should be folded into MAP-T by the MAP-T author or 4RD-U
> from the 4RD-U authors, both on and off list.

I don't know about off-list, but to say differently what think:
- abandoning the new idea expressed in the 464XLAT would be a very bad idea
- OTOH, dealing with it in the context of 4rd-U seems to me a good idea (unify stateless UE behaviors so that they can work consistently both in networks using stateful NAT64s and those using using with stateless ISP nodes)
- working together for this to happen in Softwire would be welcome on my side.

BTW, if you can take the time to read the 4rd-U draft, your questions and comments will be most welcome. 

>  It seems the softwire
> folks see 464XLAT as a competing technology.

I am an active Softwire guy, and don't see it that way.

> IMHO, MAP-T and 4RD-U do
> not solve *my* problems.

4rd-U isn't frozen yet.
I see solving your problem as an objective.

>  We took time to document how 464XLAT is
> unique in the draft.
> 
> I have brought to softwires the concern that stateless core NAT64 is
> not acceptable given the address efficiency issues (please don't blast
> me about how my issues are non-issues).

I never did, I hope, but I think I rather asked about real order of magnitudes of your problem.
Didn't get it yet.
Ideally that would include the number of simultaneous devices to be supported, and the size of the IPv4 space available, with lengths of IPv4 prefixes that compose it.
In any case, your requirement is yours,  and some other operators do have different requirements (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html).
That's why some coordination makes sense.
 
>  On the softwire list, i
> brought this up and was told a /14 of IPv4 was probably needed to meet
> a mid to large size wireless operator.  
> Unfortunately, these address
> are not available in APNIC today and will not be available in ARIN or
> RIPE in the very near future.... considering the timeline scope the
> IETF operates at.  That said, the stateless solutions have an audience
> with network operators that already have large allocations and wish to
> be more efficient.  That's great, live and let live.
> 
> Also, the MAP family is quite complicated for me and lack of trial
> deployment at scale is a concern since the IPv4 exhaustion issue is
> pressing.

I share this view on current MAP documents.

OTOH, I do think that making UEs that would support a 4rd-U, completed with permitted RFC1918 addresses in customer sites, would largely increase their applicability with a limited enough added complexity.


> I hope you see that 464XLAT is an operational solution without any
> novel technology.

In my understanding, 464XLAT does introduce a quite useful technology that is almost completely based on existing pieces, like 6rd,  but this doesn't exclude these two from being NEW technologies. 


Regards,
RD