Subject: Re: [BEHAVE] Comments on draft-wing-behave-learn-prefix-03

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Jul 2009 16:16:37 -0700

> -----Original Message-----
> From: Dave Thaler [mailto:[email-masked]] 
> Sent: Monday, July 20, 2009 3:50 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: Behave WG
> Subject: Comments on draft-wing-behave-learn-prefix-03
> 
> Attached are my comments on this draft.
> 
>  
> 
> A few high level points:
> 
> 1)      The principles in RFC 5505 are particularly relevant 
> to this discussion.

Ok, I read RFC5505's section 2.  Can you provide more guidance.  Are you
saying principle 1 (Minimize Configuration) applies so strongly that we
shouldn't configure this on a host, or that principle 2 (Less Is More) applies
so strongly that we should have only one prefix (instead of multiple)?

> 2)      As noted in 
> draft-thaler-behave-translator-addressing-00 section 2.1.4, 
> it should not assume there's only one prefix.

The draft supports three prefixes: unicast, ASM, and SSM.  But I think you're
saying it should support multiple prefixes for each of those.

If a host knows there are several IPv6 prefixes -- each prefix associated with
one IPv6/IPv4 translators -- how would a host decide which prefix to use?
Section 2.1.4 is quiet on that point.  

If the translators are stateful, it's important that the state move around
(somehow) or that the host stick with the same translator unless the host is
willing to the abandon state of the old translator.  If the translators are
stateless this isn't as important.  So, I think you're suggesting we should
tell the host if the translation is stateful or stateless (so it could 'stick'
with one prefix), or we should tell the host that the translators coordinate
their state?  I'm still not sure how the host would choose; round robin, I
guess?

> 3)      If a mechanism other than DNS is used to learn the 
> prefixes, I don't believe it's good to require DNSSEC to 
> validate the information learned.

Me, neither.  But I don't know how else to validate such
information.  For example, DHCP authentication requires
a shared secret between the DHCP client and DHCP server;
this is difficult -- at best -- to deploy and manage.

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Jul 2009 23:26:48 +0000

> From: Dan Wing [mailto:[email-masked]]
> Sent: Monday, July 20, 2009 4:17 PM
> To: Dave Thaler; [email-masked]; [email-masked]
> Cc: 'Behave WG'
> Subject: RE: Comments on draft-wing-behave-learn-prefix-03
>
>
>

How the principles apply is intentionally left as an exercise for the WG :)

Principle 1 just says don't configure things that can be automatically
learned, which doesn't really apply in any obvious way here.

Principle 2 says we shouldn't invent a new config mechanism when
an existing one will do, and also make sure the config mechanism is
supportable by minimal footprint devices and pre-boot environments.
I think all three possibilities are ok here.

Principle 3 implies we should pick preferably a single mechanism, not 3.

However I should have says "the discussion in RFC 5505" since I was
more referring to some of the issues in section 3, such as fate sharing.
But again I didn't have a specific conclusion yet.

> saying it should support multiple prefixes for each of those.

Right that's what I'm saying

> Section 2.1.4 is quiet on that point.

If a host gets multiple AAAA's back from DNS, how would it decide?
Whatever the answer is, it's generally the same answer as for the
question you asked.  For example, it might be RFC 3484, or it might
be a SHIM6 failure detection algorithm, or whatever else.

> this is difficult -- at best -- to deploy and manage.

For DHCP, I'd suggest it's validated the same way as any other
information in DHCP... there's no argument as to why this information
is more important than any other information (like DNS server IP).
Either you have some way to authenticate the set of options,
or you're willing to live without it.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 20 Jul 2009 16:43:55 -0700

> Sent: Monday, July 20, 2009 4:27 PM
> To: Dan Wing; [email-masked]; [email-masked]
> Cc: 'Behave WG'
> > shouldn't configure this on a host, or that principle 2 
> (Less Is More)
> > applies

Yeah, I was getting that impression from the RFC.

> But again I didn't have a specific conclusion yet.

Knowing, or not knowing, your stateful translators prefix doesn't
create more fate sharing.  Rather, the existence of state outside
of the end hosts creates the fate sharing.  At least, that's my
view at the moment.  :-)
 
> be a SHIM6 failure detection algorithm, or whatever else.

Alright.

> > willing to the abandon state of the old translator.  If the 
> translators
> > are
> > tell the host if the translation is stateful or stateless 
> (so it could
> > 'stick'

I see your point.  I'll think about this some more.  Thanks.

-d

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Jul 2009 23:55:44 +0000

[snipping to just the fate sharing discussion]

> of the end hosts creates the fate sharing.  At least, that's my

There are two aspects to fate-sharing:

a) If the entity you need to learn the information is down, does that
   mean the information would be useless anyway?

   For example, RAs are ok here since if the router is down you can't
   get to the translator anyway.  DNS is semi-ok since if it's down,
   and it's your DNS64, then you're semi-hosed anyway.  By semi-,
   I mean scenarios where you need to learn the prefix in order to
   deal with DNS responses (e.g. for validating stub resolvers, for
   correctly sorting native above translated addresses, etc.) but
   not ok for non-DNS scenarios where you wouldn't have any DNS
   dependency.  DHCP is the least ok in this metric (but the best
   in other metrics which you may gather from my detailed comments
   in the doc, so fate-sharing needs to be weighed against
   other goals).

b) If the entity you need to learn the information is misconfigured
   with the wrong prefix, does that mean the information would
   be useless anyway?

   Here, all three proposals are equally bad, except when the
   translator itself is acting as the DNS server, DHCP server, or
   RA sender.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Mon, 20 Jul 2009 22:50:00 +0000

A few high level points:

1)      The principles in RFC 5505 are particularly relevant to this discussion.

2)      As noted in draft-thaler-behave-translator-addressing-00 section 2.1.4, it should not assume there's only one prefix.

3)      If a mechanism other than DNS is used to learn the prefixes, I don't believe it's good to require DNSSEC to validate the information learned.

-Dave

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 22 Jul 2009 11:57:55 +0800

Hi Dave,

Thanks a lot for your comments, and I think most of them are correct. Here I
just  reply the following two of your comments.

Comment [DT1]: This is not the only (or perhaps even the most important)
reason to learn the prefix. Another reason is to do appropriate sorting of
IPv6 addresses between native vs translated.

[XH]: Once one uses one of the mechanisms described in this draft to learn
the prefix64 and uses it to synthesize IPv6 addresses,  is it still
necessary to use other mechanisms (e.g. DNS64) to obtain the translated
addresses? 

Comment [DT15]: Disadvantage is configuring the information in every router,
rather than only in a small number of DHCP or DNS servers. 

[XH] :Yes, the manual configuration option for the RA mechanism is not
optimal. Hence, we introduce some extention to the IGP ( e.g., OSPF Router
Information Opaque LSA ) for advertising the prefix64. In this way, the edge
routers could learn the prefix64 automatically which not only reduces the
manual configuration task but also avoid the possibility of
mis-configuartion.

Xiaohu 

________________________________

	发件人: Dave Thaler [mailto:[email-masked]] 
	发送时间: 2009年7月21日 6:50
	收件人: [email-masked]; [email-masked]; [email-masked]
	抄送: Behave WG
	主题: Comments on draft-wing-behave-learn-prefix-03

	A few high level points:

	1)      The principles in RFC 5505 are particularly relevant to this
discussion.

	2)      As noted in draft-thaler-behave-translator-addressing-00
section 2.1.4, it should not assume there’s only one prefix.

	3)      If a mechanism other than DNS is used to learn the prefixes,
I don’t believe it’s good to require DNSSEC to validate the information
learned.

	-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 Jul 2009 17:07:27 +0000

> necessary to use other mechanisms (e.g. DNS64) to obtain the translated

I think your question is whether plain DNS (not DNS64) can be used if
you do synthesis in the host.  I believe the answer is yes, but DNS64
is still needed for unmodified hosts in the same network.

The other thing to keep in mind is that applications use a variety
of mechanisms, which might be implemented in the application or in
the host OS.  My main point however was that the prefix is needed
for reasons other than just synthesis.

It also occurs to me that if you're doing synthesis in the end host
you need more than just the prefix (learning the prefix only is
sufficient for distinguishing native from translated though).
Specifically you need to know what algorithm is used after the
prefix.  So either the whole world has to agree on only one,
or else there has to be some identifier that allows extensibility
in the future.  Which of those two possibilities is the right one
is an open issue.

> manual configuration task but also avoid the possibility of

Yes, and that's significantly more complex than either of the other two
alternatives in the doc, especially because of the variety of IGPs.

-Dave

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 23 Jul 2009 10:58:31 +0800

Hi Dave,

> > [XH]: Once one uses one of the mechanisms described in this 
> draft to 
> > learn the prefix64 and uses it to synthesize IPv6 addresses,  is it 
> > still necessary to use other mechanisms (e.g. DNS64) to obtain the 
> > translated addresses?
> 
> I think your question is whether plain DNS (not DNS64) can be 
> used if you do synthesis in the host.  I believe the answer 
> is yes, but DNS64 is still needed for unmodified hosts in the 
> same network.

I guess your point is : The unmodified hosts co-exsit with the upgraded
hosts in the same network. The DNS64 will return them the AAAA records
(either native or synthesized) corresponding to the AAAA request, no matter
they are unmodified or not. For upgraded hosts, they can identify whether
the received AAAA record is native IPv6 address or not by using the learnt
prefix64. If the end-host is dual-stack and the received IPv6 address is
synthesized, it can use the IPv4 address for communication.

Is my understanding right? 

> The other thing to keep in mind is that applications use a 
> variety of mechanisms, which might be implemented in the 
> application or in the host OS.  My main point however was 
> that the prefix is needed for reasons other than just synthesis.

Yes, I fully agree.

> It also occurs to me that if you're doing synthesis in the 
> end host you need more than just the prefix (learning the 
> prefix only is sufficient for distinguishing native from 
> translated though).
> Specifically you need to know what algorithm is used after 
> the prefix.  So either the whole world has to agree on only 
> one, or else there has to be some identifier that allows 
> extensibility in the future.  Which of those two 
> possibilities is the right one is an open issue.

Maybe we should extend a field to identify the algorithms for address
synthesis.
 
> > Comment [DT15]: Disadvantage is configuring the information 
> in every 
> > router, rather than only in a small number of DHCP or DNS servers.
> >
> > optimal. Hence, we introduce some extention to the IGP ( e.g., OSPF 
> > Router Information Opaque LSA ) for advertising the 
> prefix64. In this 
> > way, the edge routers could learn the prefix64 
> automatically which not 
> > only reduces the manual configuration task but also avoid the 
> > possibility of mis-configuartion.
> 
> Yes, and that's significantly more complex than either of the 
> other two alternatives in the doc, especially because of the 
> variety of IGPs.

Yes, the extention to IGP will introuce some complexity, However, this
method can avoid mis-configuration and reconfiguration when the prefix64 of
the translator changed. By the way, the extention of IGP (e.g., a new TLV of
the OSPF RI opaque LSA) is transparent to the internal routers. In other
words, only the translator routers and the edge routers need upgrade. The
internal routers which don't know this extension will flood the LSAs as
normal.

If we have to reduce the number of the possible mechanisms for prefix64
learning, I prefer the DHCP and the RA options, rather than the DNS option.
The reason is: 1)  DHCP and RA are two basic mechanisms for IPv6 address
auto-configuration, relying on some extension to either of them is
reasonable; 2) The DNS server used by the end hosts (or some applications on
the end-host ) may not be the local DNS server operated by the same operator
of the IPv6 site network where the end hosts are located. One example is:
some applications prefer to use the intelligent third-party DNS server,
which could provider the nearest server address according to the client's
address, rather than the default DNS server learnt from the DHCP option. Of
course, it would be better if we could remain all three mechanisms.

Xiaohu

 _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave