Subject: Situation with draft-ietf-v6ops-v6onbydefault-03.txt

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Nov 2004 16:22:43 +0200 (EET)

Hi,

Alain wanted to raise the issue on what's up with 
draft-ietf-v6ops-v6onbydefault-03.txt.

At the IESG evaluation, two people raised a particular significant 
concern: the document should not be discussing solutions to these 
problems, if the solution has not been advanced in the appropriate WGs 
or other fora.  (It would be OK to just write about the problems, 
however.)

These seem to be two ways forward here:

  1) make sure work on the solutions is moving forward in the 
appropriate WGs, etc., and wait until publishing this document, with 
mentioning the solutions.  Drawback is that it may take long time to 
get these merged in the specification efforts.

  2) remove all the references to solutions in this document (I believe 
most of this was already done in -03 revision).  Drawback is that the 
document is much less useful as it is, and we still need to make sure 
these things actually get fixed.  Just describing problems doesn't 
really help all that much unless they're also fixed...

I've personally favoured 1).

Are there opinions on the approach?

For what it's worth, the status wrt solutions is as follows:
  - draft-gont-tcpm-tcp-soft-errors-01.txt (presented twice at TCPM WG 
meetings) describes the "soft error" behaviour, and is being actively 
debated at TCPM WG right now.  Generally, these has been positive 
reaction, except from a particular TCP purist (or two)  who seem to be 
resisting very strongly making any TCP modifications and instead 
advocating changing all the applications, etc., and requiring all 
kinds of evidence that this fix does not have ill effects.

  - this has been raportedly integrated with SCTP spec (by the SCTP 
authors) as well (I haven't checked), and mentioned to DCCP people. 
I haven't checked whether newest DCCP specs conform to this behaviour.

  - the onlink assumption is dependent on rfc2461bis (which is OK now) 
which is now at WGLC.

  - no work has been done on RFC3484 rule wrt. "unreachable 
destination", but this didn't seem needed as the removal of onlink 
assumption and ICMP soft errors should do the job.  Should there be 
some?

  - the VPN problem is an implementation issue; has it been reported to 
the vendor?  Is there a PR or some other identification tag for it?

  - the application transition document is already done so application 
robustness is OK.

So, in summary, it seems all of this is in a relatively good swing, 
except for the TCP modification which is facing some resistance. 
Unfortunately, that is probably the most important fix that should go 
in...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Nov 2004 10:27:12 -0800

> draft-ietf-v6ops-v6onbydefault-03.txt.

Thank you for starting this thread. Please note that there is also a 
companion draft,
draft-ietf-v6ops-onlinkassumption-02.txt that provides that rationale 
for the change in
RFC2461 about on-link assumption. What should we do about this draft?
	- publish it as Info RFC to document the rationale for the change in 
the update of RFC2461?
	- same thing, but publish it simultaneously as 2461bis?
	- let it expire has it has served its purpose.

> most of this was already done in -03 revision).

Yes, -03 has removed any references to solutions.

> [...]

There is another aspect, which is what to publish in the DNS, and this 
is where there is
overlap with the draft in DNSop "don't publish unreachable". 
Essentially, publishing IPv6 addresses
in the global DNS when one does not have global IPv6 connectivity is no 
different than
publishing IPv4 RFC1918 type addresses...

About default address, there is an issue for apps that are using UDP 
and are (miss?)configured
with an unreachable literal IPv6 address. This is typically the case 
for a DNS stub-resolver
that is configured with a list of literal addresses. We had to 
introduce an extra rule
to take care of that.

If you are confident that progress can be made quickly on all those 
fronts, it may be worth
holding back the publication of the draft until resolution of those 
issues, however, i have to admit that
I'm a bit pessimistic...

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Nov 2004 20:59:36 +0200 (EET)

On Thu, 18 Nov 2004, Alain Durand wrote:
> companion draft, draft-ietf-v6ops-onlinkassumption-02.txt that 
> provides that rationale for the change in RFC2461 about on-link 
> assumption. What should we do about this draft?

It's in the similar state as this document; the second seems to make 
most sense (if it's not merged back to v6onbydefault), as RFC2461(bis) 
does not document the justification for the on-link assumption or its 
removal, and I think it'd be useful to have a document to show to 
people who would come up and ask why this is done.

> There is another aspect, which is what to publish in the DNS, and 
> this is where there is overlap with the draft in DNSop "don't 
> publish unreachable". Essentially, publishing IPv6 addresses in the 
> global DNS when one does not have global IPv6 connectivity is no 
> different than publishing IPv4 RFC1918 type addresses...

Agree.  This was a tricky document with no clear progress at dnsop 
meeting.  Someone should take it up, and document the issues with 
general unreachable address publication, as well as tradeoffs with ULA 
or similar addresses in the DNS.

> and are (miss?)configured with an unreachable literal IPv6 address. 
> This is typically the case for a DNS stub-resolver that is 
> configured with a list of literal addresses. We had to introduce an 
> extra rule to take care of that.

Could you elaborate a bit what you mean by that?

> fronts, it may be worth holding back the publication of the draft 
> until resolution of those issues, however, i have to admit that I'm 
> a bit pessimistic...

The difficult part is being able to make progress with the TCP 
modification.  Within a couple of weeks, I believe there will be 
better knowledge how it turns out.  If you care, you could check the 
tcpm WG archives for the (long) thread, and see if you have something 
to contribute.

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Nov 2004 11:35:13 -0800

On Nov 18, 2004, at 10:59 AM, Pekka Savola wrote:

>> this is where there is overlap with the draft in DNSop "don't publish 
>> unreachable". Essentially, publishing IPv6 addresses in the global 
>> DNS when one does not have global IPv6 connectivity is no different 
>> than publishing IPv4 RFC1918 type addresses...
>

Tim Chown & I have half committed to take that one

>> This is typically the case for a DNS stub-resolver that is configured 
>> with a list of literal addresses. We had to introduce an extra rule 
>> to take care of that.
>

I have to take my previous statement back, I was a bit confused.
I meant to refer to the suggested rule 2.5 for address selection in
section "2.1  Problems with Default Address Selection for IPv6"
of draft-ietf-v6ops-v6onbydefault-03.txt

It essentially says that choosing a src address with different 
reachability
properties than the destination address (here src = link local, dst = 
global,
but there might be other bad combinations with ULA) is a bad idea.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Nov 2004 13:32:23 +0200 (EET)

On Thu, 18 Nov 2004, Alain Durand wrote:
>>> There is another aspect, which is what to publish in the DNS, and this is 
>>> where there is overlap with the draft in DNSop "don't publish 
>>> unreachable". Essentially, publishing IPv6 addresses in the global DNS 
>>> when one does not have global IPv6 connectivity is no different than 
>> Agree.  This was a tricky document with no clear progress at dnsop meeting. 
>> Someone should take it up, and document the issues with general unreachable 
>> address publication, as well as tradeoffs with ULA or similar addresses in 
>> the DNS.
>

Great!

>>> About default address, there is an issue for apps that are using UDP and 
>>> are (miss?)configured with an unreachable literal IPv6 address. This is 
>>> typically the case for a DNS stub-resolver that is configured with a list 
>>> of literal addresses. We had to introduce an extra rule to take care of 
>>> that.
>> 
> reachability properties than the destination address (here src = 
> link local, dst = global, but there might be other bad combinations 
> with ULA) is a bad idea.

So, this is something that we need to keep bugging IPv6 WG about, I 
guess?

Maybe we need a (short) draft to describe the issues and possibly 
suggest solutions..