Subject: RE: IETF 57 Multu6 WG - Monday morning session - minutes

From: Geoff Huston <[email-masked]>
Date: Tue, 15 Jul 2003 19:12:20 +1000

stream of conciousness typing is not always accurate - I'll correct this

   Geoff

At 01:40 AM 15/07/2003 -0700, Christian Huitema wrote:
>Geoff,
>
>Thanks for the notes. You made a slight typo in the reporting of my talk, 
>when you wrote "We appear to
>be able to design solutions that require changes to the IPv6 standards, do
>no require address rewriting at exit points, but it could work". What I 
>said was, "We appear to
>be able to design solutions that ^do not* require changes to the IPv6 
>standards, do
>not require address rewriting at exit points, and could work."
>
>There is also a small typo in a response to Pekka. You wrote:
>
>PN: You need to change the address in both ends.
>CH: The time appears to be around 5 or 6 minutes.
>
>
>The actual question was "you need to change code at both ends" (as 
>Marcello explained, you need to do something to some MIPv6 timers to be 
>more efficient). The response was, "You don't need to change code if you 
>are satisfied with the default timers, which appears to be around 5 or 6 
>minutes."
>
>-- Christian Huitema
>
>
>
>
>________________________________
>
>From: [email-masked] on behalf of Geoff Huston
>Sent: Mon 7/14/2003 10:02 AM
>To: Kurt Erik Lindqvist; [email-masked]
>Cc: [email-masked]
>Subject: IETF 57 Multu6 WG - Monday morning session - minutes
>
>
>
>Multi 6 Monday 1300 - 1500
>
>Agenda - overview of submitted drafts
>
>Agenda bashing: none
>
>
>- - draft-nikander-hip-mm-00.txt, Pekka Nikkander, 5 min
>
>
>          For background:
>          draft-moskowitz-hip-arch-03.txt
>          draft-moskowitz-hip-07.txt
>
>    Host Identity Protocol (HIP) has been around for some time. New
>namespace protocol with a history of around 4 years. Today sockets are
>bound to IP addresses, forcing the IP address into a dual role of endpoint
>identifiers and forwarding identifiers. HIP introduces a new namespace
>between the network and transport layers. The sockets are bound to host
>identifiers that are dynamically bound to IP addresses. Hosts are
>identified with public keys, not IP addresses, and apps see only the HIP
>identifiers. The apps need not change is the assertion. Hosts can easily
>have both IPv4 and IPv6 addresses, and the assertion is that end-host
>multi-homing and mobility is trivial. HIP Proxies are described as a kind
>of a hack. HIP may be a part of the multi-homing architecture. 4
>Interoperating implementations, intend to send the drafts to the IESG, and
>more work is needed on mobility and multi-homings with NAT traversal. HIP
>is not a working group but is progressing in the background. HIP is a
>multi-address solution with end-to-end. It solves only one aspect of
>multi6, and has no specific solns for address selection or TE
>
>Matsataka Ohta: You said "HIP Proxy" - do you support multi-proxies for backup
>Pekka Nikkander: There is no easy way to have multi HIP proxies in some
>situations, and it does represent a single point of failure
>
>
>
>- - draft-coene-sctp-multihome-04.txt, Lode Coene, 15 min
>
>
>    SCTP approach - endpoints have multiple addresses, where each IP address
>represents a path to a particular endpoint. SCTP is not aware of the level
>of path distinguishing - it would be good if they were, but this is not a
>known property. SCTP can detect path up/down. (Example of host-to-host with
>2 addrs on each host). Multi-homing open up new horizons for SCTP: add and
>remove ip addresses dynamically to the endpoint, that can support mobility.
>Functionality at the endpoint is asserted to be superior to network
>functions in this regards. It does imply that the host requires a routing
>table - not a big deal for a host is the claim. But a big table is required
>for a system with a large connection load. How to maintain the routing
>table is claimed to be implementation dependant (pre-configured or caching
>the INIT). NATs are in the draft because they wanted to warn everyone how
>bad NATs really are! NAT cases for SCTP generates problems that do no
>appear to have straightforward solutions. From the transport level SCTP is
>claimed to be a 'should work' solution.
>
>Lixia Zhang: How about UDP?
>Lode Coene: its the same problem, with the application having to undertake
>the selection.
>Erik Nordmark: what algorithms have been used in SCTP work to select source
>and destinations? Any write ups of this work?
>Lode Coene: none known to me.
>
>
>
>- - draft-bagnulo-multi6-mnm-00.txt, Marcelo Bagnulo, 10 min
>
>    Proposes to use MIPv6 to the multi-homing (mh) problem. Example in
>presentation of recovery from current to backup path (Using alternate
>addresses) Both paths have to be bound and identified _before_ an outage
>using binding update messages. The alternate binding will use the Home
>Address Option. Since MIP already needs the exchange of messages along each
>path, this exchange can be used as a path keepalive. The lifetime of the
>binding is limited to 7 minutes, and this is considered to be very short.
>Possible solutions are proposed
>
>Matsataka Ohta: IPv6 has large timeouts for various purposes. If your
>proposal to have the same property so that the new address can be used 
>quickly.
>Marcelo Bagnulo: this issue is to build a path outage detection, and we are
>proposed to use the packet exchange for this purpose. The idea is to use
>the same packet format, but change the timing.
>
>
>- - draft-ohta-e2e-multihoming-05.txt, Masataka Ohta, 20 min
>
>    General introduction on IP and IPv6. References 8+8 Locator and endpoint
>I-D. The proposal is to let end systems have multiple addresses. Let the
>other end select the 'best' address. (The host addresses are part of
>multiple upstream aggregates). The general architecture proposed is to let
>the network inform the host about state to allow the hosts to undertake
>address selection. When should a host attempt alternate addresses? Proposed
>in response to ICMP, routing change, timeouts (TCP only). Proposed that
>applications have an IP (and UDP)-defined packet timeout to trigger
>alternate address use. For very short timeouts it is proposed to send
>multi-copies of the packet with multiple addresses. e-2-e mh and IP
>mobility are similar, although there is mobility timing at the IP layer.
>e2emh has been implemented and running on NetBSD with LIN6, with
>modifications to the stack as described in the presentation. The design
>framework proposed is to make everything optional. Exercising no options is
>single-homed. Use 8+8 Locator/Id separation, with packet reception and
>connection identification determined by the ID. Application to mobility is
>also described. Multiple addresses are supplied to the peer by reverse
>query of DNS using an ID query key followed by a forward query, or carry in
>the TCP header or a new DNS query type. e2e approach is proposed as
>scaleable architecture. MH and mobility are related, and the approach uses
>8+8 separation
>
>Pekka Nikkander: You did not mention security issues in your presentation -
>is this to be addressed later on, or do you have comments now?
>Matasaka Ohta: The current Internet is weakly secure. Cookie-based security
>for locator change give only the same level of security.
>
>Peter Werny: What is required in the DNS for this to work?
>Matasaka Ohta:  this is different from current V6, as it only uses the
>identifier 8 bytes. In DNS we look up locators of location agents using ID
>of hosts.
>Peter Werny: Every host has to have a DNS entry?
>Matasaka Ohta:If there is no DNS and not TCP then you are single-homed, and
>you cannot use this mechanisms.
>PW: Your draft has no mention of DNS update
>Matasaka Ohta: Location is not in the DNS - just the location agent.
>Erik Nordmark: Are you assuming a structure for the identifiers?
>Matasaka Ohta: It should be reverse lookup-able. Its better to have
>hierarchy in the identifier space, but you can do without hierarchy if you
>use TCP instead of the DNS to pass the multiple addresses
>
>
>
>- - draft-ohira-assign-select-e2e-multihome-00.txt, FUJIKAWA Kenji, 5 min
>
>    Each end application can determine a route to use. Applications select a
>route using a selection of a specific source and destination address pair.
>An end application can select a path without full route information is the
>claim. The attributes are claimed to include redundancy and load balancing.
>Modifications to hosts, routers and routing protocols is needed. Site exit
>router selection using source address routing enables redundancy, load
>sharing with multiple paths. Some mechanisms is needed for 'proper' source
>address selection. Transport layer survivability could be an SCTP mechanism
>or other.
>
>
>
>- - draft-arifumi-lin6-multihome-api-00.txt, Arifumi Matumoto, 10 min
>
>    Socket API extensions. Propose to use application layer, rather than the
>network. Uses 8+8 model. The API is for manipulation of multiple addresses
>in the application. LIN6 is based on the 8+8 model. LIN6 does address
>acquisition, notification, registration in a secure manner. Hosts identify
>their peer and themselves using only the identifier part. e2e-mh is seen to
>be an application of the LIN6 model. The trigger to switch locators is seen
>to be ICMP-based using host unreachable. APIs need to manipulate locators,
>to make a multi-locator-ready socket, allow API to change locators on the
>fly, and acquire remote locators. The details of API changes described, in
>socket(), getaddrinfo() and getsockopt()/setsocketopt(). APIs are intended
>for active mh applications. UDP requires application support. Future work
>is to put support in to the TCP level, so that no changes are required for
>API for TCP.
>
>
>- - draft-ohta-multihomed-isps-00.txt, Masataka Ohta, 10 min
>
>    All hosts should have full default-free routing table. This allows
>selector in host to make optimal locator choice, and know when locator is
>unreachable. source address selection for ingress filtering only. The peer
>will not use the source address - it will make its own selection of a
>locator for the peer. Extended example of policy control and filtering.
>
>
>Pekka Savola: Both of these drafts have been obsoleted
>Matasaka Ohta: not a problem!
>? (MCI): IF an NLA gets address space from 2 TLAs which does it use?
>MO: If gets 2 addresses, as does its customers. The number of prefixes
>cascades down.
>? MCI): Scaleaility?
>MO: yes, and NLA should be no more than triply homed.
>Iljitsch van Beijnum: Why is the information in the routing table superior
>to information you can obtain from the other end?
>MO: This does not have scaleability problems if you limit connectivity.
>This is a connectionless system where a host has no information about the
>other end, and the routing table is local information you can use.
>Iljitsch van Beijnum: ok, but I disagree with this
>
>
>
>- - draft-de-launois-multi6-naros-01.txt, Cedric de Launois, 10 min
>
>
>    Solution for traffic engineering for mh need sites in a multi-address
>environment. Each host has 1 address per upstream provider. Noted that
>choosing a source address implies choosing a provider (assuming providers
>perform source address filtering). Which source? A host has no information
>about which provider to use to reach a destination. Propose to use a
>dedicated agent (server). A host will query the server with a destination
>address, and the server responds with the source to use. The burden of
>selecting the source address is aggregated to a dedicated server. Note it
>gives only a hint to the host about what address to use. NAROS is not
>intended to preserve flows across address changes. SCTP or HIP could be
>used to preserve flows. The server could be anycast, or undertaken without
>provider interaction. The host / server protocol is a query response packet
>exchange. Where multiple choices exist, multiple parameters can be used to
>make the selection.
>
>Pekka Nikkander: is this a new protocol, or, perhaps, ICMP
>Cedric de Launois: No particular protocol - it could be ICMP
>PN: There are security issues here, like secure neighbor discovery
>Michael Richardson: Takes the example and adds further connections, and
>then adds a policy question about 'acceptable traffic' policies. Can NAROS
>deal with this>
>CdL: A lot of requirements could be placed in the NAROS server and it could
>be aware of those kind of requirements.
>Matsataka Ohta: Anycast does not include increased robustness for server
>failure. A NAROS server crash will not bring down a anycast route. Also 300
>seconds is too large a value.
>
>
>
>- - draft-huitema-multi6-hosts-02.txt, Chistian Huitema & David
>     Kessens, 20 min
>
>    Simple multihoming experiment. A problem statement in a bounded example
>environment. A simple network is a single link where multiple hosts see
>multiple boundary routers where each router is connected to distinct
>upstreams. Addresses from providers are mapped to all the hosts. Asserted
>that this is not uncommon in V4 and that the common solution is to NAT the
>local net and allow the NAT to 'rehome' to each outbound. The consequence
>is flow breakage across the rehoming of the NAT. The bounds are that the
>ISPS do not exchange information, there are provider addresses with an
>assigned prefix per provider. Hosts configure an address with each prefix.
>Need to resolve host choice of egress router selection (as a function of
>the source address)
>
>Erik Nordmark:  There are people talking about movement detection, and this
>gets all routers to advertise all prefixes
>Christian Huitema: Thats not incompatible - several routers can advertise
>the same information, provided that the information is equivalent, and the
>routers can handle all such packets.
>Pekka Savola: please clarify the applicability. This is only the case where
>hosts are directly connected to all egress routers.
>Christian: this is a common case.
>MO: You don't need tunnels in a single link network. In a multi-link
>network you need tunnels.
>CH: This does nothing for MTU discovery. For single link there is a very
>simple solution and this can be extended for multi-links
>MO: Ands I'm saying its impossible
>CH: fine!
>
>    No need for tunnels in a single link network, and the routers can pass
>off to each other in the event of dynamic failure. The assertion is that in
>a single link network this requirement can be easily met. Dead exist
>routers or dead ISP require some consideration. If the exit router knows
>that the path is dead it can send a poison advertisement of the prefix. The
>real issue with this form of mh is a very soft definition of 'broken' where
>the link may be up, but the path to the remote end point may be unuseable.
>This kind of problem is an e2e detection issue. Hosts may need to keep
>track of connections and track quality. If you know an ingress path is dead
>do you need to update the DNS to remove the dead prefix from your host
>entry? Of course you may not know and in this case your peer will need to
>work out what address to use. Maintenance of TCP connections is an issue.
>MIP6 may be an answer, or SCTP for 'new hosts'. For 'old' hosts, he
>connection will fail, and needs to be reestablished. Exit / entrance
>selection is also an issue. One approach is to only advertise the preferred
>address in the DNS if you have a primary / backup scenario. And in a 1 + 1
>scenario, then advertise both. On the outgoing the solution may be a local
>server to assist, or to document preferences in the routers. We appear to
>be able to design solutions that require changes to the IPv6 standards, do
>no require address rewriting at exit points, but it could work,
>
>Pekka Nikkander: New hosts can use MIPv6 or SCTP. IN MIPv6 don't you need
>to change both ends?
>CH: The support for the connected node in MIPv6 is supposed to be
>implemented everywhere.
>PN: You need to change the address in both ends.
>CH: The time appears to be around 5 or 6 minutes.
>PN: If you are going to change the code at both ends then you should try
>HIP in your experiments as well.
>CH: You are free to experiment with HIP
>Fujikawa: It seems like an application cannot select different path from
>other applications in a host?
>CH: No, not so. The host has several IPv6 addresses. An application that
>want to do path selection can bind to a source address and connect to a
>destination and select a path.
>Matasaka Ohta: It is stupid to keep using a complication MIPv6
>CH: Complexity is management of the Home agent and security functions to
>certain classes of attacks and you will need  to have some form of security
>in any case.
>Matasaka Ohta: This only works in a single link case.
>
>    In a larger site the problem is ingress filtering, because its harder to
>do source-based routing. The simple solution is to work with the ISP to
>lift source filters. Even larger sites have their own PI space and AS#.
>
>IvB: Disable ingress filtering can be down for the local upstream, but the
>chain may extend upward
>CH: ingress filtering in the middle of the Internet is a bad idea
>MO: what will you do with a large site?
>CH: lets call them medium
>Bob Hinden: ISPs would be more amenable to break ingress filtering than
>route specifics.
>?: Ingress filtering should not be an issues.
>Mat Ford: Define a large site?
>CH: establish a registry relationship!
>
>
>- - draft-savola-multi6-asn-pi-00.txt, Pekka Savola, 10 min
>
>
>    Claimed that this is not the best solution in all cases, but better than
>some others. Need to avoid the routing mess of advertising more specific
>and need solutions soon. Approach to use the AS number to create PI space
>for larger enterprises. e.g. 2000:<ASN>::/32. Issues about 16 / 32 bit AS
>numbers, and a claim that 32 bit AS numbers would indicate a RIR policy
>failure.
>
>
>
>Moshens VC(?): How do you get uniqueness of the prefix
>PS: This is 2000 - it won't collide!
>MO: There are already too many ASes deployed
>Geoff Huston: You are assuming AS remain at 16bits. What happens when AS
>drain in 2011. and we move to 32 bit AS numbers? This is a relatively short
>term solution with a visible drop dead point - right?
>PV: yes.
>?: This is good solution
>PV: an appendix shows how to deal with 32 bit AS numbers, but I don't lkike
>this solution.
>Tim Chen: This cuts out the smaller sites that do not have ASs.
>Randy Bush: Why reluctant to give out ASes to routing domains who's policy
>domains are different from their neighbors?
>
>
>- - draft-van-beijnum-multi6-isp-int-aggr-01.txt, Iljitsch van Beijnum,
>     15 min
>
>
>    Geographical aggregation. Admitted that topology is not correlated to
>geography, and even if the geo part doesn't work there are still some savings.
>
>MH: This gives little actual aggregation
>?: Asymmetrical routes break in your model
>IvB: Routing is asymmetrical in multi-homing in any case.
>Tony Hain: Aggregatibility is the question. The concept appears fine, but
>you are making assumptions about aggregation boundaries here.