Re: NAT64 in RA, draft-ietf-6man-ra-pref64

[Jen Linkova <[e-mail]>]

On Sun, Jun 30, 2019 at 7:50 AM Mark Andrews <[e-mail]> wrote:
>
> Well the information in needed the moment you use the DNS64 prefix anywhere else than in the setup for a virtual interface.

I think the point is that information is needed only of the host has a
dual-stack interface and is using DNS64 (and there is a NAT64
somewhere behind that interface).
What I'm trying to say is that scenario looks very special and I'm
sure people are doing it in real life ex. for some experiments.

>The only reason you can get away with it in that scenario is that the routing table acts as a filter and only then if you have the node learning the routes and it is not relying on default to reach the rest of the internal subnets.

Not sure I understand what you mean.
Let's say there is a node connected to an IPv6-only LAN.
Scenario 1: the node has one route, ::/0 pointing to the router LLA.
Scenario 2: the node has a number of more specific routes, pointing to
some other LLAs.

How does it different for NAT64/DNS64 case with or without APL?

> Adding it in a second option also increases the RA overhead. Your main objection it that it increases the size of the RA option but you want to add the overhead of a second RA option.

I'm not sure there will be an overhead in case of two options.
[Disclaimer: writing this before my first coffee, so please
double-check my math]

If /96 prefix is used (remember, in that case to have the APL the
pref64 option would need to include all 128 bits of the prefix and the
prefix length so we are adding 64 bits of the overhead)

Case 1: the APL name is 24 bits or shorter
if we include it in the pref64 option, then we can keep Len = 3, so 192 bits
Separate options: the new option would have length = 1, and the pref64
option would have length = 2, total length of both options = 3, 192
bits. No overhead.

Case 2:  24 bits < the APL length  < 48 bits
If included in pref64 option: length = 4 (or 256 bits)
Separate option: length = 1, the pref64 option length = 2. Still 192
bits, We are even saving the bits.

Case 3: 48 bits < The APL name < 88 bits
If included into pfe64: len = 4 ( 256 bits)
The separate option would still have the length = 2. Pref64 option
length = 2. No overhead.

Case 4: 88 bits < the APL < 112 bits
If included into pfe64: len = 5
The separate option: len = 2. Pref64 len = 2. Having a separate option
saves bits.

etc.
If we look at random example of an APL name using 20 bytes:
- having it in the pref64 option: the option len = 6
- with two separate options: pref64 len = 2; the APL option len = 3 =>
the total len = 5.
Again, it's better to have a separate one.

> Go try and set up a validating DNS64 server on a tethered host and see if you can.

Tethered like 'tethered to a phone which is connected to v6-only network'?


> On 29 Jun 2019, at 10:38, Lorenzo Colitti <[e-mail]> wrote:
>
> On Sat, 29 Jun 2019, 04:01 Michael Richardson, <[e-mail]> wrote:
>>
>>     > As a co-author, I don't see a real operational need for this at the moment.
>>     > Why is this not something that we can define later on in its own draft,
>>     > once we get more support for it and consensus that it is a useful thing to
>>     > do?
>>
>> I'm not okay with this: I'd really like to be able to specify this in an RFP.
>> I'm okay with the mechanism being optional to support.
>
>
> That was not my point. My point was: why does this functionality need to be in this option? Why does it need to be in this draft? For example - why can't you and Mark submit a separate draft - at your earliest convenience - defining a new RA option to do this?
>
> Particularly given that you're saying this would be optional to implement, it seems natural to have two different options.
>
--
SY, Jen Linkova aka Furry