Re: [pcp] Multi-homed NAT (was: What's the final conclusion?答复: [Technical Errata Reported] RFC6887 (3887))

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Zhangzhan (Channy) [mailto:[e-mail]]
> Sent: Wednesday, February 12, 2014 7:44 PM
> To: Dave Thaler; Dan Wing
> Cc: Ted Lemon; PCP Working Group; Stuart Cheshire;
> [e-mail] Boucadair; Reinaldo Penno;
> [e-mail]; Brian Haberman
> Subject: 答复: Multi-homed NAT (was: What's the final conclusion?答复:
> [Technical Errata Reported] RFC6887 (3887))
> 
> To Dave:
> 
> Based on my understanding for your meaning:
> It's more appropriate to select an optimal one instead of default behavior in
> this scene.
> 
> But in such a network topology:
> 
>                                                    ,-----.
>                                                  ,'       `.
>                                                .( ISP1 )
>               ,-------.                     .-'  `.       ,'
>            ,-'  ISP0   `-.                .'       `-----'
>         Host              \ CGN        .-'          ,-------.
>     +----+-----+       +---+------+  .'           ,'         `.
>     |PCP Client|-------|PCP Server|.'------------( ISP2)
>     +----+-----+       +---+------+ `-.           `.         ,'
>           \               /            `.           `-------'
>            `-.         ,-'               `-.      ,-----.
>               `-------'                     `.   /       \
>                                               `-( ISP3 )
>                                                  \       /
>                                                   `-----'
> 
> If users in ISP1 want to visit the host in ISP0, suppose the global nat address
> of host is IP pool 1.
> Normally, if no PCP, if users in ISP2 want to visit the host, the global nat
> address of host is IP pool 2.
> IP pool 1 and IP pool 2 are certainly different address segments, and
> belonging to different ISP.
> 
> Now PCP is used to mapping the global nat address, suppose CGN select IP
> pool 1 as the optimal one. If users in ISP2 want to visit the host, must visit the
> IP pool 1 through ISP1's network. But usually this is not acceptable to IPS2.

Yes that diagram is a different scenario than the one you originally mentioned,
where all connect to the Internet.  (There is no Internet in your picture here.)

This is the scenario Dan was referring to.

-Dave
 
> -----邮件原件-----
> 发件人: Dave Thaler [mailto:[e-mail]]
> 发送时间: 2014年2月13日 11:03
> 收件人: Dan Wing
> 抄送: Zhangzhan (Channy); Ted Lemon; PCP Working Group; Stuart
> Cheshire; [e-mail] Boucadair; Reinaldo Penno;
> [e-mail]; Brian Haberman
> 主题: Multi-homed NAT (was: What's the final conclusion?答复: [Technical
> Errata Reported] RFC6887 (3887))
> 
> Updating subject line.
> 
> More below.
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[e-mail]]
> > Sent: Wednesday, February 12, 2014 6:55 PM
> > To: Dave Thaler
> > Cc: Zhangzhan; Ted Lemon; PCP Working Group; Stuart Cheshire;
> > [e-mail] Boucadair; Reinaldo Penno;
> > [e-mail]; Brian Haberman
> > Subject: Re: What's the final conclusion?答复: [Technical Errata
> > Reported]
> > RFC6887 (3887)
> >
> >
> > On Feb 12, 2014, at 6:35 PM, Dave Thaler <[e-mail]> wrote:
> >
> > >> -----Original Message-----
> > >> From: Dan Wing [mailto:[e-mail]]
> > >> Sent: Wednesday, February 12, 2014 6:23 PM
> > >> To: Zhangzhan
> > >> Cc: Ted Lemon; PCP Working Group; Stuart Cheshire;
> > >> [e-mail] Boucadair; Reinaldo Penno;
> > >> [e-mail]; Brian Haberman; Dave Thaler
> > >> Subject: Re: What's the final conclusion?答复: [Technical Errata
> > >> Reported]
> > >> RFC6887 (3887)
> > >>
> > >>
> > >> On Feb 12, 2014, at 5:29 PM, Zhangzhan (Channy)
> > >> <[e-mail]> wrote:
> > >>
> > >>> Maybe you misunderstand me.
> > >>> There is only one router for NAT and PCP.
> > >>> If the NAT gateway device (such as CGN) is PCP Server and has two
> > >>> or more
> > >> out interfaces to internet were doing different nat conversion in the
> ISP.
> > >>> Maybe using NAT address pool A, B, C... And the routing entries to
> > >>> internet
> > >> on NAT gateway is equivalent default route. In this case, the out
> > >> interface is uncertain, fully in accordance with the equivalent
> > >> route
> > selection.
> > >>> If no PCP, service traffic can be selected out interface according
> > >>> to the
> > >> destination address and do different NAT conversion.
> > >>> But the PCP message is in before the normal service traffic. And
> > >>> PCP MAP
> > >> mode message does not include the destination address, the NAT
> > >> gateway device how to choose the out interfaces and the different
> > >> NAT address pools?
> > >>> Based on the current PCP protocol, I think that can't be solved.
> > >>> Or what I
> > >> understand something wrong?
> > >>
> > >> With such a network topology, you are correct that the current MAP
> > >> opcode doesn't work.
> > >
> > > I'm not sure it's fair to say it "doesn't work".  It just means that
> > > the NAT picks one using any implementation-specific mechanism.  In
> > > the stated example above, both possible answers go to the Internet,
> > > so what
> > wouldn't "work"?
> >
> > Good point.  Same with a TCP SYN -- it gets assigned to one CGN, or
> > the other
> > -- it wouldn't be assigned to both.  I had figured that both don't
> > really, really, go to the Internet, like what NTT does with their IPv6
> > default route in Japan (which doesn't go to the Internet).
> 
> Yes that's an alternate example that's good to discuss (hence the change in
> subject line), which draft-penno-pcp-zones does.  In a multi-homed NAT
> case, I'd expect the implementation to prefer the one that actually goes to
> the Internet.
> That is, since MAP tries to open a port for "anyone", then when multiple
> choices exist that support different sets of remote peers, one should by
> default prefer the one with the larger set, as being closer to the desire of
> "anyone".
> 
> And of course there could be implementation-specific configuration to
> override the default, or protocol support a la draft-penno-pcp-zones to
> specify non-default behavior.
> 
> -Dave
> 
> >
> > -d
> >
> >
> > >
> > > On the topic of the errata, I agree with Ted it is not an errata.
> > > It's simply an implementation detail that the RFC doesn't specify,
> > > so it's up
> > to the reader.
> > >
> > > -Dave