Re: [alto] Suresh Krishnan's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS)

[Sebastian Kiesel <[e-mail]>]

Suresh,

thanks for the feedback. please see below:

On Wed, Dec 05, 2018 at 08:05:19AM -0800, Suresh Krishnan wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-alto-xdom-disc-04: Discuss
> 
> * Section 5.1.2.
> 
> I am having a hard time seeing how this can be implemented as described.
> 
> "Therefore, a dual stack or multihomed resource consumer SHOULD either always
> use the same address for contacting the resource directory and the resource
> providers, i.e., overriding the operating system's automatic source IP address
> selection"
> 
> What exactly is the mechanism to be used for the override? A policy table
> (manual or RFC7078)? I think it would be good if the document can provide an
> implementable description based on RFC6724.

We didn't think of a RFC6724-style policy table.  We had something in
mind like this (pseudocode for the resoure consumer, based on socket API):

>>  rd_address = gethostbyname("hostname.of.the.resource.directory.");
>>  rd_socket = socket();
>>  
>>  /* do not bind, i.e. let the OS decide which local address to use */
>>  connect( rd_socket, rd_address );
>>  
>>  /* save the chosen address for later */
>>  getsockname( rd_socket, local_address_when_querying_rd );
>>  local_address_when_querying_rd.sin_port = htons(0);
>>  
>>  resource_provider_list = query_resource_dir( rd_socket, resource_name );
>>  close( rd_socket );
>>  
>>  for( i=0 ; i < length(resource_provider_list) ; i++ ) {
>>      rp_socket[i] = socket();
>>  
>>      /* bind to the same address that we used earlier */
>>      bind( rp_socket[i], local_address_when_querying_rd );
>>  
>>      connect( rp_socket[i], resource_provider_list[i]->addr );
>>  }
>>  
>>  interact_with_resource_providers( &rp_socket );


We would have to add some fine print about cases when
local_address_when_querying_rd is a ULA or RFC1918 address.


We believe that the above solution works, but it seems not appropriate
that this sketch follows an uppercase SHOULD ...  Maybe, we could add it
as a further appendix, and refer to it in section 5.1.2.:

Therefore, a dual stack or multihomed resource consumer SHOULD either
always use the same address for contacting the resource directory and
the resource providers, i.e., overriding the operating system's
automatic source IP address selection (see Appendix D for one solution
approach), or ...


Does this make sense?  What else could we do?

> **********************************************************************
>
> * Section 3.2.  Step 1
> 
> "Similarly, if AT=IPv6 and L < 32, the procedure aborts  and indicates an
> "invalid prefix length" error to the caller."
> 
> I am trying to understand why is this a limitation. An IPv6 prefix can
> certainly legally have a length of < 32.

Of course an IPv6 prefix may have a length < 32, according to the IPv6
specifications. This is also acknowledged in the document. But we
believe that supporting prefix lengths < 32 in XDOMDISC would cause
more harm than good.

Our draft says in sec. 3.1: "for AT=IPv6, it holds: 0 <= L <= 128." 
and later in 3.2: "First, the procedure checks the prefix length L 
for unsupported values: [...] if AT=IPv6 and L < 32, the procedure aborts
and indicates an "invalid prefix length" error to the caller."

I am not sure, is your comment about the wording?  

Maybe we could improve by replacing "invalid" with "unsuppored": 

"if AT=IPv6 and L < 32, the procedure aborts
and indicates an "unsupported prefix length" error to the caller."

We would also change lines 5 and 11 in the table in sec 3.4:
   | IPv4       |   0 ..  7  | (none, abort: unsupported prefix length)|
   | IPv6       |   0 .. 31  | (none, abort: unsupported prefix length)|


Or is it about the limitation as such?

The rationale is that we want to limit the number of DNS lookups.
In the worst case, if AT=IPv6 and no relevant NAPTR records have been put
into place, we cause five DNS queries, for R128, R64, R56, R48, and R32.
We believe that this is an acceptable trade-off between seeking flexible
discovery options and avoiding excess load on the DNS.  We assume that
even in the long run, it is extremly unlikely that a prefix with L < 32
will be delegated to a single organization and operated as a monolithic
address block, regarding routing policies etc. Consequently, adding a
further Rxx (with 0 <= xx < 32) will rarely, maybe never, produce a useful
result, but will cause a futile sixth DNS query in many cases.
At the end of the day, if someone really wants that XDOMDISC discovers
the same URIs for all IP addresses in a prefix with L < 32, they can
install multiple NAPTRs, one for each /32 sub-range (maybe synthetisize
them in the name servers automatically).

Should we add this explanation to the document, or is replacing
"invalid" with "unsuppored" sufficient to address your concerns?


Thanks
Sebastian