Subject: Proposed IPv6 W.G. Agenda for Paris

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Jul 2005 15:40:27 -0700

Here is the first cut at an agenda for the IPv6 working group session at 
the Paris IETF.  Please review and send us comments, deletions, and additions.

Thanks,
Bob Hinden & Brian Haberman
IPv6 Chairs

Internet Protocol Version 6 WG (IPv6)
Tuesday, August 2, 2005
1400-1600 Afternoon Session I
--------------------------------------

Introduction, Call for Scribes,         Hinden          05 minutes
and Agenda Bashing

Document Status                         Haberman        05 minutes

IPv6 Node Information Queries           Haberman	10 minutes
   Goal: Close open issues
   draft-ietf-ipngwg-icmp-name-lookups-12.txt

IPv6 Address Allocation to End Sites    Narten          20 minutes
   Goal: Discussion
   draft-narten-ipv6-3177bis-48boundary-00.txt

IPv6 over IEEE802.16                    Kim		10 minutes
   Goal: New draft, Initial Discussion
   draft-jin-ipv6-over-ieee802.16-00.txt

URI Syntax                              Fenner          15 minutes
   Goal: Make decision to adopt proposal
   draft-fenner-literal-zone-01.txt

Implementation Reports for              Haberman        10 minutes
Privacy Extensions for Stateless Address
Autoconfiguration in IPv6
   Goal: Call for reports

Next Steps for IPv6 w.g.                Hinden          15 minutes
Advancing core specification to Standard
   Goal: Discussion

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sat, 23 Jul 2005 14:01:10 +0900 (JST)

Bob,

 | Here is the first cut at an agenda for the IPv6 working group session at 
 | the Paris IETF.  Please review and send us comments, deletions, and additions.

Could you please give me a few minutes for following draft?

  Title:   Distributing Default Address Selection Policy using DHCPv6
  Filename: draft-fujisaki-dhc-addr-select-opt-00.txt

As a result of a discussion at last IETF dhc wg, I need ipv6 wg
support to move forward this draft.

As I posted before, this draft describes the RFC3484 policy table
distribution (please refer http://www.nttv6.net/dass).

Yours sincerely,

--
Tomohiro Fujisaki

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 27 Jul 2005 21:00:00 +0900

>>>>> On Sat, 23 Jul 2005 14:01:10 +0900 (JST), 
>>>>> [email-masked] said:

> support to move forward this draft.

I've read the latest draft, but I'm afraid the document itself doesn't
help assess whether the ipv6 wg can support that or not, since it
mainly concentrates on the DHCPv6 specific issues.

I believe what should be discussed in this group is the intended

> distribution (please refer http://www.nttv6.net/dass).

I've read this page, too.  My current impression is that "I see some
point, but I'm not sure if it's enough for introducing a new DHCPv6
option".

Specifically,

> Case1: IPv4 or IPv6 Prioritization

I see this is a case where the automatic policy distribution may
help.  But since the address selection by RFC3484 is much more
powerful than just selection between IPv4 and IPv6, I don't think this
can be a convincing usage if this is the only meaningful case.

> Case2: ULA or Global Prioritization
> Case3: Multicast Source Address Selection

For these cases, using a non default policy table could resolve the
issue (and automatic policy distribution would help), but I personally
think this should be rather dealt with through a clarification for the
"default" selection rule, with the fact that site-local unicast
addresses were deprecated and ULAs are introduced.

> Case4: Global and Closed Mixed Connectivity

This may look a valid use case superficially, but people will actually
wonder why ISP2 needs (or can have) global (non ULA) addresses, or
even any IPv6 addresses, to begin with, if it's not connected to the
global Internet.  And, for example, if the closed network uses ULAs
and we clarify the "default" address selection policy, we'll be just
happy with the clarified default policy (we may also need the new
'/54' allocation policy as well, though).  Or, if ISP2 just uses
private IPv4 addresses, we'll just be happy even with the current
default rules.  Unless the usage example answers to this natural
question, I'm afraid this will look artificial (and thus cannot be
convincing).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Jul 2005 14:23:01 +0200

> scenarios (the "Practical Usage" section) described in this URL:

Yes, I believe the most important know is whether such an option is
useful or not. So one question is how common it will be to have non-
default policies. Another is how it might be autoconfigured. If a
site has a large number of clients that needs a non-default policy,
then some way of distributing that policy to the clients is needed.

There are also some technical issues, but those can perhaps be
discussed later. Mainly how to represent the different values like
precedence, label, scopeid etc. 3484 doesn't really describe the
datatypes in detail.

E.g. zone-index in draft-fujisaki-dhc-addr-select-opt-00.txt is
suggested to be one byte, which I'm not sure is sufficient.

Also the label is a single byte which might be fine. Some
implementations of 3484 seem to have long text strings as labels,
but hopefully they could also cope with short numerical strings
like "1" and "100".

> > Case2: ULA or Global Prioritization

When using ULAs and globals together, I think you may want different
rules depending on whether you have peerings with other sites using
different ULA IDs or not.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Jul 2005 15:36:41 +0300 (EEST)

> addresses were deprecated and ULAs are introduced.

This brings up another point which has been brought up in the past. 
There is an agenda item for progressing the base IPv6 spec to full 
standard.

I suggest we move that discussion to happen prior to this 
presentation, and augment the discussion to include revising RFC3484 
(and moving it to Draft Standard).

-- 
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: Arifumi Matsumoto <[email-masked]>
Date: Thu, 28 Jul 2005 17:28:57 +0900

I'm co-author of this draft and web-page.
Thank you for comments, Jinmei-san ,Stig.

> scenarios (the "Practical Usage" section) described in this URL:

At first, we planned to publish another Internet-Draft
that describes practical usages of this DHCP option.
But we found that these usages are almost the same
as those written in Section 10 of RFC 3484.

So, instead of writing another draft, I summarized
some issues related to our proposal in this web page,
which includes implementation status of address selection
policy table, abstract of our proposing DHCP option and
usages of it. To show all of you the related information
at a glance.

This is an excuse for not writing a Internet-Draft. ;)

> addresses were deprecated and ULAs are introduced.

As you mention it, if ULA's address scope is defined like
Scope(link-local) < Scope(ULA) < Scope(Global),
the case 2 problem will be solved.

As Stig has pointed out, however, defining an appropriate
scope for ULA doesn't solve all the problems related to
ULA site, which I described below.

> question, I'm afraid this will look artificial (and thus cannot be

As for this point, we've had a related dialogue just before
the previous IETF meeting on dhcwg ML, which I paste below.

A VPN connectivity and a native IPv6 connectivity environment
can be an answer to the first question. That is, a site has a
native IPv6 connectiviy and also has a VPN connection, over the
native IPv6 line, to another site that doesn't provide transit
connectivity to a VPN-connected site. In this case, the same
problem occurs as the case 4.

In addition to this, what we believe is that ASP services like video
streaming, ip phone, security service and home appliance maintenance
will be getting into home networks and this trend has already started
to happen.
Even if each of these ASPs uses ULA, address selection problem
occurs once one of them has a peering with another site or
once one of them acquires another ULA block.

thanks.

Begin forwarded message:

> From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[email-masked]>
> Date: 2005年3月10日 13:57:42:JST
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [dhcwg] comments on draft-hirotaka-dhc-source-address-selection-opt-01.txt
> X-Mailer: Mew version 4.2 on XEmacs 21.4.15 (Security Through Obscurity)
>
>
>
> Junmei-san,
>
> Thank you for reading our draft in detail.
>
>  | Substantial comments (or questions)
>  | 
>  | 1. at least from this document, it's not clear whether we really need
>  |    this kind of generic DHCPv6 option.  In particular, the assumption
>  |    in section 6 that ISP1 doesn't have global connectivity while ISP2
>  |    does seems very artificial.  I cannot understand why we are
>  |    suddenly led to this example.
>
> We believe that the closed network example is not artificial.  There
> will be some cases that users want to use multiple connections
> simultaneously, such as global connectivity and VPN,  and global
> connectivity and some kind of ASP services (Video streaming, IP Phone
> and maintenance of home appliances). Actually, some implementation
> of IP phone already uses closed network model.
>
>  |    If this option is useful for a general multihome case, the draft
>  |    should first discuss that case (rather than the odd-looking
>  |    unbalanced example).  But it does not seem to be the case to me (or
>  |    at least it's not clear to me).
>  | 
>  |    What happens if both ISP1 and ISP2 have global IPv6 connectivity?
>  |    Can this option help something in this case?
>
> CPE router can inform nodes which prefix should be used to a
> destination prefix (in this situation, CPE router will inform
> the nodes which uplink is selected as default).
>
>  |    On the other hand, assume neither ISP1 nor ISP2 has global IPv6
>  |    connectivity.  Then isn't it enough to let the "longest-matching"
>  |    rule of RFC3484 do the job for avoiding the trap of ingress
>  |    filtering?
>
> Basically yes. 
>
> However, end user network knows assigned prefix information only
> and it has no information abut other prefixes that upstream ISPs
> may have. This may be covered if routing information is available,
> but in this case, other problem will occur (I'll describe below). 
>
>  |    I also have a question from yet another point of view.  In the
>  |    "unbalanced" example of Section 6, the essential information for
>  |    the "user router" seems the fact packets to A::/32 should be sent
>  |    to ISP1 and others (including ::/0) to ISP2.  This is, in essence,
>  |    just routing information.  Since we already need some kind of
>  |    routing information in the typical PD usage, I don't see the need
>  |    for the redundant information baring the new DHCPv6 option.
>
> There are some cases that address selection policy cannot be created
> from the routing information.
>
> For example, 
>  - a router that advertise routing information and a DHCP-PD server is
>    the different node.
>
>  - a DHCP-PD server wants to assign multiple prefixes that have
>    different selection policy.
>
> In these cases, it is generally impossible to make relationships
> between routing information and assigned prefix.
>
>
>  |    BTW: in the case of the PD usage, the "assigned" prefix (e.g.,
>  |    A::/48) should be provided in the PD framework, so this information
>  |    in the SASP option seems redundant.
>
> If the DHCP-PD router assigns only one prefix, it may be surely
> redundant to have the prefix value in SASP option.  But it is
> necessary to keep the relation of assigned prefix and SASP policy,
> when it delivers multiple prefixes and multiple policies.
>
>  |    I see we may need some new mechanism between the user router and
>  |    end nodes in order to relate the routing information (e.g., the
>  |    default route is the path to ISP2) to source address selection
>  |    rules, in order to avoid the ingress filtering trap.  But, in this
>  |    case, I think we only need a single mechanism, whether it's DHCPv6
>  |    or RA.  Remember that even an end host that configures addresses by
>  |    stateless address autoconfiguration may still need DHCPv6 for
>  |    getting (recursive) DNS server addresses.  Similarly, even an end
>  |    host that configures addresses by DHCPv6 will still need RAs to get
>  |    on-link prefixes.  So, a single mechanism would be enough for
>  |    providing source address selection rules, whether it's RA or
>  |    DHCPv6, and whether receiving node uses RA or DHCPv6 for address
>  |    configuration.
>
> Well, I think I have to look into more about this issue, whether DHCP
> is always vital for every node or not.
>
>  |    BTW: the source address selection problem with ingress filtering is
>  |    exactly what one of general multihoming issues.  So, one may ask
>  |    for discussing this in the context of (e.g.) multi6 wg.  We'll at
>  |    least need to be asked why we cannot use solutions being considered
>  |    in multi6.
>
> Surely, ingress filtering issue in multiple global network connectivity 
> environment is multi6 matter. Our proposal can solve this issue as I
> stated above, and I believe that our proposal can go well with the 
> coming multi6(shim6) new proposal for the hints of source address selection.
>
> Actually, we made a presentation at multi6 meeting in DC, and multi6
> chairs advised us multi6 does not target the closed network case.
>
>
>  | Semi-substantial comments
>  | 
>  | 2. the scenario described in this draft seems to assume (perhaps
>  |    implicitly) that the user router can get all the prefix information
>  |    (from ISP1 and ISP2) at once.  However, the PD procedures with the
>  |    ISPs should in general be asynchronous events.  So, the user router
>  |    should somehow deal with the asynchronous information for providing
>  |    consistent rules with end nodes.  It's not very clear from the
>  |    current draft on how the user router behaves wrt this concern.
>  |    (Perhaps this is not a serious issue...I'm just not sure about this
>  |    from the current text)
>
> This asynchronous behavior doesn't lead to such a serious trouble,
> I agree that I have to mention about it too.
>
>  | 3. In section 6, the draft says:
>  | 
>  |    o  End nodes set up their IPv6 addresses by using a stateful DHCPv6
>  |       function or receiving router advertisement message.  They also
>  |       request the SASP option by transmitting Information-Request
>  |       messages to the router.
>  | 
>  |    But if the end node uses DHCPv6 for address set-up, it should also
>  |    be able to get the SASP option in this procedure; I don't see why
>  |    the node needs to transmit Information-Request in this case.  (But
>  |    see also the more fundamental question above).
>
> Absolutely. I'll correct it soon.
>
>  | 4. Also in Section 6,
>  | 
>  |    o  When the requesting client detects a change in a delegated address
>  |       or address prefix, it requests the Source Address Selection Policy
>  |       option again.
>  | 
>  |   This statement is not very clear to me.  What is the "requesting
>  |   client" in this context?  Is it the user router, a end node, or
>  |   both?  (Perhaps the definition in Section 3 is not very clear in the
>  |   first place)  Also, how does it "request" the option again?
>
> I fully agree that this sentence is surely ambiguous.
>
> What I wanted to say is:
>
> - a prefix and a source address selection policy is strongly bound.
> - when a prefix is invalidated, the corresponding source address 
>   selection policy also has to be invalidated.
>
> We'll rewrite this part.
>
>  | 5. In section 7,
>  | 
>  |    A malicious DHCPv6 client may be able to mount a denial-of-service
>  |    attack by sending repeated requests for the Source Address Selection
>  |    Policy option, thus exhausting the DHCP server's resources.
>  | 
>  | I'm not really sure about the point of this statement.  What kind of
>  | "server's resources" are concerned here?  Since the SASP is quite
>  | stateless, shouldn't the "malicious" client consume further
>  | "resources" such as address/prefix pools?  Or, does this sentence
>  | considers the processing load at the sever side?  But if so,
>  | 
>  |    To guard against attacks, both DCHP clients and servers SHOULD use
>  |    DHCP authentication, as described in section 21 of RFC 3315,
>  |    "Authentication of  DHCP messages."
>  | 
>  | I don't think this is very accurate.  A malicious client can still
>  | bother the server, consuming the server's resource of processing load,
>  | by sending repeated requests with bogus authentication information.
>
> We will also rewrite security consideration section.
>
>  | Editorial comments
>  | 
>  | 6. In section 1, second paragraph
>  |    s/packet- forwarding/packet-forwarding/
>  | 
>  | 7. there's a mixture of "usable" and "useable" in the second bullet of
>  |    Section 6.  This should be consistent.
>  | 
>  | 8. In section 7, last paragraph
>  |    s/"Authentication of  DHCP messages."/"Authentication of DHCP messages."/
>  |    (there's a redundant white space)
>
> Thank you very much.
>
> Yours sincerely,
> --
> Tomohiro Fujisaki
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

--
Arifumi Matsumoto <[email-masked]>
  Ubiquitous Computing Project
  NTT Information Sharing Platform Laboratories
  TEL: +81-422-59-3334 / FAX: +81-422-59-5652